Expose git_merge_file function from libgit2 to repo.rs of git2-rs by kvzn · Pull Request #635 · rust-lang/git2-rs

kvzn · 2020-11-22T07:55:35Z

No description provided.

alexcrichton · 2020-11-23T16:45:53Z

libgit2-sys/lib.rs

+    pub len: size_t,
+}
+
+extern "C" {


Could this get merged (hah!) with the general block of function definitions elsewhere in this file?

I was worrying to make it mess at the beginning so they were put together, now they've been moved to the right places.

alexcrichton

Thanks for this!

src/lib.rs

alexcrichton · 2020-11-23T16:47:37Z

src/lib.rs

+    }
+}
+
+impl Into<u32> for FileMode {


FWIW this is typically phrase as From<FileMode> for u32, but if FileMode is an enum I think it would be better to set the discriminants to the raw::* values and that way enum_value as u32 should work for this purpose.

So we don't need Into<u32> trait implementation but just use file_mode as u32 when needed?

alexcrichton · 2020-11-23T16:48:58Z

src/merge.rs

+
+impl MergeFileResult {
+    /// Create MergeFileResult from C
+    pub fn from_raw(raw: raw::git_merge_file_result) -> MergeFileResult {


I think this'll want to be unsafe?

I have used unsafe at the specified lines, is that ok?

impl MergeFileResult { /// Create MergeFileResult from C pub fn from_raw(raw: raw::git_merge_file_result) -> MergeFileResult { let c_str: &CStr = unsafe { CStr::from_ptr(raw.path) }; // unsafe let str_slice: &str = c_str.to_str().unwrap_or("unknown path"); let path: String = str_slice.to_owned(); let content = unsafe { slice::from_raw_parts(raw.ptr as *const u8, raw.len as usize).to_vec() }; // unsafe MergeFileResult { automergeable: raw.automergeable > 0, path: Some(path), mode: raw.mode.into(), content: Some(content), } } }

Ah the unsafe part is that this is taking a raw C structure where the pointers aren't guaranteeed to be valid, so the unsafe signals "the caller needs to take care of that validity"

Understood, than you!

alexcrichton · 2020-11-23T16:50:04Z

src/repo.rs

+            let result = MergeFileResult::from_raw(ret);
+
+            // FIXME: need to free????
+            raw::git_merge_file_result_free(&mut ret as *mut _);


Typically this is modeled by MergeFileResult taking ownership of the git_merge_file_result and is then responsible for any deallocation necessary, would that be possible here?

So raw::git_merge_file_result_free(&mut ret as *mut _); is not needed?

kvzn · 2020-11-24T02:58:17Z

@alexcrichton BTW, could you point out how I can fix the issue in CI / Test (windows)? Tried but have no idea.

alexcrichton

Oh the windows error I think has to do with the fact that enums in C have a different signededness than other platforms. I think you can probably fix things with some casts?

src/lib.rs

alexcrichton · 2020-11-25T17:12:16Z

src/merge.rs

+
+impl MergeFileInput {
+    /// Create from Repository and IndexEntry
+    pub fn from(repo: &Repository, index_entry: &IndexEntry) -> MergeFileInput {


FWIW I've personally shied away from helper functions like this in the past for this crate. This crate tries to stick pretty close to libgit2's own API without adding too many Rust helpers and such. Is there a particular reason though that we should have this when libgit2 doesn't?

Understood, it's removed now.

alexcrichton · 2020-11-25T17:13:03Z

src/merge.rs

+
+impl MergeFileResult {
+    /// Create MergeFileResult from C
+    pub fn from_raw(raw: raw::git_merge_file_result) -> MergeFileResult {


Ah the unsafe part is that this is taking a raw C structure where the pointers aren't guaranteeed to be valid, so the unsafe signals "the caller needs to take care of that validity"

alexcrichton · 2020-11-25T17:13:43Z

src/merge.rs

+    pub mode: FileMode,
+
+    /// The contents of the merge.
+    pub content: Option<Vec<u8>>,


FWIW I think this would probably be best done by (privately) containing raw::git_merge_file_result and providing accessors for each field. That way Rust doesn't need to allocate anything unnecessarily.

Great, improved.

alexcrichton · 2020-11-25T17:14:17Z

src/merge.rs

+    }
+
+    /// File content, text or binary
+    pub fn content(&mut self, content: Option<Vec<u8>>) -> &mut MergeFileInput {


I think it might actually be best to take &[u8] here and tie the lifetime to MergeFileInput so that way users won't have to copy data around.

Yes, improved.

alexcrichton · 2020-11-25T17:14:43Z

src/merge.rs

+    path: Option<CString>,
+
+    /// File mode of the conflicted file, or `0` to not merge the mode.
+    pub mode: Option<FileMode>,


These fields should be private so alterations are forced to go through public functions.

Also I think it's ok to eschew storing mode here, we can just store it directly in the raw field.

Yes, fixed that

alexcrichton · 2020-11-25T17:15:44Z

src/repo.rs

+            ours_raw = ptr::null();
+        }
+        if let Some(theirs) = theirs {
+            theirs_input = MergeFileInput::from(&self, theirs);


FWIW I think it would be best to take theirs: Option<&MergeFileInput> in this function instead of doing this computation internally.

Understood, now it accepts Option<&MergeFileInput>

kvzn · 2020-11-26T05:19:21Z

Oh the windows error I think has to do with the fact that enums in C have a different signededness than other platforms. I think you can probably fix things with some casts?

I tried this, but doesn't work, any idea:

trait FileModeConvert {
    type ValueType;
    fn from(mode: Self::ValueType) -> Self;
}

impl FileModeConvert for FileMode {
    #[cfg(target_env = "msvc")]
    type ValueType = i32;

    #[cfg(not(target_env = "msvc"))]
    type ValueType = u32;

    fn from(mode: Self::ValueType) -> Self {
        match mode {
            raw::GIT_FILEMODE_UNREADABLE => FileMode::Unreadable,
            raw::GIT_FILEMODE_TREE => FileMode::Tree,
            raw::GIT_FILEMODE_BLOB => FileMode::Blob,
            raw::GIT_FILEMODE_BLOB_EXECUTABLE => FileMode::BlobExecutable,
            raw::GIT_FILEMODE_LINK => FileMode::Link,
            raw::GIT_FILEMODE_COMMIT => FileMode::Commit,
            mode => panic!("unknown file mode: {}", mode),
        }
    }
}

kvzn · 2022-05-20T07:33:41Z

@alexcrichton Can we merge this PR now? Thank you!

rustbot · 2025-01-20T16:33:58Z

☔ The latest upstream changes (possibly f095112) made this pull request unmergeable. Please resolve the merge conflicts.

kvzn force-pushed the expose-merge-file branch 4 times, most recently from cc83880 to 4a39ad8 Compare November 22, 2020 09:03

Expose git_merge_file function from libgit2 to repo.rs of git2-rs

57766bc

kvzn force-pushed the expose-merge-file branch from 4a39ad8 to 57766bc Compare November 22, 2020 09:13

alexcrichton reviewed Nov 23, 2020

View reviewed changes

Improvements

6ba9e96

alexcrichton reviewed Nov 25, 2020

View reviewed changes

kvzn force-pushed the expose-merge-file branch 2 times, most recently from 490bafa to 80bcd0b Compare November 26, 2020 05:16

kvzn force-pushed the expose-merge-file branch from 80bcd0b to c6f0fca Compare November 26, 2020 05:33

Improvements

2b5b1dd

kvzn force-pushed the expose-merge-file branch from c6f0fca to 2b5b1dd Compare November 26, 2020 06:05

Improve

0736d2c

kvzn force-pushed the expose-merge-file branch 2 times, most recently from 478bc5b to 0736d2c Compare November 26, 2020 09:06

Fixed bug of smoke_merge_file

ed71b2d

kvzn force-pushed the expose-merge-file branch from 72aa4af to ed71b2d Compare November 27, 2020 05:45

Merge branch 'master' into expose-merge-file

ea795f5

MikeJerred mentioned this pull request Jun 23, 2024

Add function: git_merge_file_from_index #1062

Merged

rustbot added the S-waiting-on-author Status: Waiting on PR author label Jan 20, 2025

chalharu mentioned this pull request Jan 25, 2026

Add function: merge_file #1210

Open

Conversation

kvzn commented Nov 22, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvzn commented Nov 24, 2020

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvzn Nov 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvzn Nov 26, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvzn commented Nov 26, 2020

Uh oh!

kvzn commented May 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kvzn Nov 26, 2020 •

edited

Loading

kvzn Nov 26, 2020 •

edited

Loading

kvzn commented May 20, 2022 •

edited

Loading