# Re: Avoiding uninteresting merges in Cairo 8 messages from 2006-12-15 to 2006-12-15. Participants: Jakub Narebski, Shawn Pearce, Carl Worth, Junio C Hamano. Thread: https://gitlist.dev/t/43411 ## Shawn Pearce, 2006-12-15 02:06 Subject: Avoiding uninteresting merges in Cairo Message-ID: <20061215020629.GK26202@spearce.org> URL: https://gitlist.dev/e/20061215020629.GK26202%40spearce.org ``` I was just talking with jwatt today in #git and he pointed me at the following email from http://lists.freedesktop.org/archives/cairo/2006-April/006648.html after he had a merge gone wrong in his working directory and was asking for help. Cario has seriously been using `reset --hard HEAD^` as part of its workflow since April? Why haven't you pushed for a rebase merge strategy to be tried before a trivial index merge as an option in git-merge (e.g. pull.twohead=rebase recursive)? -- ``` ## Carl Worth, 2006-12-15 03:17 Subject: Re: Avoiding uninteresting merges in Cairo Message-ID: <87tzzx4zm7.wl%cworth@cworth.org> URL: https://gitlist.dev/e/87tzzx4zm7.wl%25cworth%40cworth.org In-Reply-To: <20061215020629.GK26202@spearce.org> ``` On Thu, 14 Dec 2006 21:06:29 -0500, Shawn Pearce wrote: > http://lists.freedesktop.org/archives/cairo/2006-April/006648.html > > after he had a merge gone wrong in his working directory and was > asking for help. > > Cario has seriously been using `reset --hard HEAD^` as part of its > workflow since April? I wrote that in April, but I've never pointed anyone at it since then. I've learned a lot since then, (and git has changed too). One thing I've been meaning to do is to write up a more complete introduction on using git to manage cairo's tree to put into cairo's wiki or so, (it would have helped a newcomer like jwatt here). > Why haven't you pushed for a rebase merge > strategy to be tried before a trivial index merge as an option in > git-merge (e.g. pull.twohead=rebase recursive)? I've mentioned it as an idea once or twice on this list. I've never "pushed" for any change along these lines simply because I haven't ever done any implementation for this. Also, I don't actually need this. I don't use the "reset --hard" workflow suggested in the mail above. I always obtain remote changes with "git fetch" and then examine things locally and decide to either merge (or fast forward) with "git pull", (though maybe I'll start using "git merge" now), or else to use "git rebase" to avoid the noisy merge commits. That workflow of fetching changes and then exploring them locally before merging is why I rarely take advantage of the combined fetch+merge aspect of "git pull". It's exceedingly rare for me to ever call "git pull" with any URL but ".", (though I use "git fetch" with various URLs on a regular basis). -Carl PS. It's funny how much easier it is to type "cario" than "cairo". I used to do that all the time, (though in this sentence here, when I actually _tried_ to type "cario" it came out as "cairo" the first time). I think the "cario" typo is a Qwerty artefact---the left hand gets all its keypresses in before the right hand gets going. ``` ## Shawn Pearce, 2006-12-15 03:25 Subject: Re: Avoiding uninteresting merges in Cairo Message-ID: <20061215032530.GM26202@spearce.org> URL: https://gitlist.dev/e/20061215032530.GM26202%40spearce.org In-Reply-To: <87tzzx4zm7.wl%cworth@cworth.org> ``` Carl Worth wrote: > One thing I've been meaning to do is to write up a more complete > introduction on using git to manage cairo's tree to put into cairo's > wiki or so, (it would have helped a newcomer like jwatt here). I saw three things happen to poor jwatt that really threw him for a loop, and I think they are all more likely related to Git than to the Cairo project specifically: * His user.name/user.email is probably not what he wanted; * His Cygwin/Windows system made some *.c/*.c files 0755 without him realizing it; * gitweb made it appear as though a whole lot of Carl's recent work was somehow undone in the merge. -- ``` ## Carl Worth, 2006-12-15 04:01 Subject: Re: Avoiding uninteresting merges in Cairo Message-ID: <87slfh4xkm.wl%cworth@cworth.org> URL: https://gitlist.dev/e/87slfh4xkm.wl%25cworth%40cworth.org In-Reply-To: <20061215032530.GM26202@spearce.org> ``` On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote: > I saw three things happen to poor jwatt that really threw him for > a loop, and I think they are all more likely related to Git than > to the Cairo project specifically: Yes. Also a fourth one was a filesystem case-insensitivity issue. We recently imported an external library into cairo that had some filenames with capital letters. We then renamed them to the all-lowercase filenames we like. Poor jwatt was unlucky enough to have cloned with a capitalized filename, and then was trying to pull the latest with the lowercase filename and he got: fatal: Untracked working tree file 'test/pdiff/lpyramid.h' would be overwritten by merge This was in some sense worse than the other problems since it stopped him cold and gave him no idea what was wrong nor how to fix it. > * His user.name/user.email is probably not what he wanted; > > * His Cygwin/Windows system made some *.c/*.c files 0755 without > him realizing it; Those two issues did silently put garbage in the commits. I don't know how to best fix the name/email thing. Maybe on the first commit with no user.name and user.email configuration git could create them, announce them to the user, and instruct them on how to change them: No name or email configuration exists. Using: U-JONATHAN-X60S\jonathan You can change these with the following commands: git repo-config user.name Your Name git repo-config user.email user@example.com And maybe mention --global as well. As for the filemode setting, shouldn't that be configured by default the right way for Windows git? > * gitweb made it appear as though a whole lot of Carl's recent > work was somehow undone in the merge. That looks like a simple gitweb bug. None of the other tools, (gitk, git log -p), consider a trivial merge commit like this as having anything interesting in it worth displaying. -Carl ``` ## Shawn Pearce, 2006-12-15 07:53 Subject: Re: Avoiding uninteresting merges in Cairo Message-ID: <20061215075357.GA27964@spearce.org> URL: https://gitlist.dev/e/20061215075357.GA27964%40spearce.org In-Reply-To: <87slfh4xkm.wl%cworth@cworth.org> ``` Carl Worth wrote: > On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote: > > I saw three things happen to poor jwatt that really threw him for > > a loop, and I think they are all more likely related to Git than > > to the Cairo project specifically: > > Yes. Also a fourth one was a filesystem case-insensitivity issue. We > recently imported an external library into cairo that had some > filenames with capital letters. We then renamed them to the > all-lowercase filenames we like. Poor jwatt was unlucky enough to have > cloned with a capitalized filename, and then was trying to pull the > latest with the lowercase filename and he got: > > fatal: Untracked working tree file 'test/pdiff/lpyramid.h' > would be overwritten by merge > > This was in some sense worse than the other problems since it stopped > him cold and gave him no idea what was wrong nor how to fix it. This is a huge problem on filesystems where case does not matter (FAT, Mac OS X's HFS+, NTFS). We really should put something into git to detect this when it happens and help the user get out of the box they have worked themselves into. > > * His user.name/user.email is probably not what he wanted; > > > > * His Cygwin/Windows system made some *.c/*.c files 0755 without > > him realizing it; > > Those two issues did silently put garbage in the commits. I don't know > how to best fix the name/email thing. Maybe on the first commit with > no user.name and user.email configuration git could create them, > announce them to the user, and instruct them on how to change them: > > No name or email configuration exists. Using: > > U-JONATHAN-X60S\jonathan > > You can change these with the following commands: > > git repo-config user.name Your Name > git repo-config user.email user@example.com > > And maybe mention --global as well. I've been thinking that is the right thing to do, somewhere in git-commit, but I can't decide if its best to save that per-repository or per user, or be interactive and get confirmation from the user, or just display it and hope the user noticed. > As for the filemode setting, shouldn't that be configured by default > the right way for Windows git? No. The problem is Git tries to be smart and see if filemode works by chmodding the config file and then looking to see if that worked the way we expected it to. It usually does on Cygwin when using NTFS. But then if you edit a file non-executable file with a native Windows application Cygwin may suddenly think its executable again, and now our core.filemode=true guess isn't actually right anymore. We probably should just hardcode core.filemode to false on Cygwin. If the user actually wants core.filemode to be true on Cygwin then he/she will probably also know enough about this issue with native Windows applications that the additional hurdle of turning on the option by hand won't be a big one for them. > > * gitweb made it appear as though a whole lot of Carl's recent > > work was somehow undone in the merge. > > That looks like a simple gitweb bug. None of the other tools, (gitk, > git log -p), consider a trivial merge commit like this as having > anything interesting in it worth displaying. Right. gitweb is doing `diff HEAD^1 HEAD` which is quite wrong on a merge commit. Especially here where the trunk was pulled into the topic branch, rather than the topic branch being pulled into the trunk. -- ``` ## Jakub Narebski, 2006-12-15 14:21 Subject: Re: Avoiding uninteresting merges in Cairo Message-ID: URL: https://gitlist.dev/e/eluasq%24v7q%243%40sea.gmane.org In-Reply-To: <87slfh4xkm.wl%cworth@cworth.org> ``` Carl Worth wrote: > On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote: >> * gitweb made it appear as though a whole lot of Carl's recent >> work was somehow undone in the merge. > > That looks like a simple gitweb bug. None of the other tools, (gitk, > git log -p), consider a trivial merge commit like this as having > anything interesting in it worth displaying. It's not a bug, it is rather lack of feature (or misfeature). Gitweb deals with multiparent commits (merge commits) that it uses _first_ parent. No special casing merges (like git-show doesn't show whatchanged/patch for merges), no support for -c/--cc diff (combined diff format). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Shawn Pearce, 2006-12-15 15:01 Subject: Re: Avoiding uninteresting merges in Cairo Message-ID: <20061215150130.GB17860@spearce.org> URL: https://gitlist.dev/e/20061215150130.GB17860%40spearce.org In-Reply-To: ``` Jakub Narebski wrote: > Carl Worth wrote: > > > On Thu, 14 Dec 2006 22:25:30 -0500, Shawn Pearce wrote: > > >> * gitweb made it appear as though a whole lot of Carl's recent > >> work was somehow undone in the merge. > > > > That looks like a simple gitweb bug. None of the other tools, (gitk, > > git log -p), consider a trivial merge commit like this as having > > anything interesting in it worth displaying. > > It's not a bug, it is rather lack of feature (or misfeature). Its a bug. I'm not a gitweb user (meaning I almost never look at something in gitweb). But I'm clearly also not a Git newbie. ;-) I could not fathom why that merge commit was being displayed that way in gitweb. I had to clone the cairo project just so I could actually look at the commit with log/show/whatchanged/diff-tree, because I couldn't believe what I was seeing from gitweb. -- ``` ## Junio C Hamano, 2006-12-15 21:03 Subject: Re: Avoiding uninteresting merges in Cairo Message-ID: <7vvekcub1i.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vvekcub1i.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <87tzzx4zm7.wl%cworth@cworth.org> ``` Carl Worth writes: > On Thu, 14 Dec 2006 21:06:29 -0500, Shawn Pearce wrote: >> ... >> Cairo has seriously been using `reset --hard HEAD^` as part of its >> workflow since April? > ... > Also, I don't actually need this. I don't use the "reset --hard" > workflow suggested in the mail above. I always obtain remote changes > with "git fetch" and then examine things locally and decide to either > merge (or fast forward) with "git pull", (though maybe I'll start > using "git merge" now), or else to use "git rebase" to avoid the noisy > merge commits. I wish I have more time to keep track of "recommended workflows" that projects using git give to its developers. I think what you recommend makes quite a lot of sense, for very centralized setting, and would leave much more usable history than the simple-minded way cvs-migration suggests. ```