Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
- From
- Peter Baumann <waste.manager@gmx.de>
- Date
- Oct 25, 2007, 07:26 UTC
- Message-ID
- <20071025072635.GC6069@xp.machine.xx>
- In-Reply-To
- <471FBF29.8030802@op5.se>
On Wed, Oct 24, 2007 at 11:54:49PM +0200, Andreas Ericsson wrote:
Show 35 quoted lines
> Peter Baumann wrote: >> On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote: >>> J. Bruce Fields wrote: >>>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote: >>>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote: >>>>> >>>>>>> I want git pull to work like git push. >>>>>> That strikes me as a less complete solution, since it only helps in >>>>>> the >>>>>> case where the other branches all happen to be unmodified locally >>>>>> (hence >>>>>> can be fast-forwarded). In other cases the "git push" will still emit >>>>>> a >>>>>> spurious error. >>>>> Well, but then there's something you should really think >>>>> about. >>>> Perhaps, but not necessarily; you may have some branches with local >>>> changes that you're content to leave unpushed (and un-updated). >>> Sure, but that won't change. The only thing I'm proposing is that >>> local copies of remote branches are automatically fast-forwarded >>> on every pull, but only if >>> >>> * the branch has no modifications what so ever >>> * the branch is set up to auto-merge with the particular branch >>> fetched from the particular remote >>> >>> I really don't see any downsides what so ever with this. Those >>> of you who do, please enlighten me. >>> >> You can't check what got added in your pull, e.g you can't review the new >> code with something like >> gitk next..origin/next > > That's what git-fetch is for. >
If I run git pull <remote> and have a auto-merge setup, I would merge the remote side into my local branch. Then doing
gitk ORIG_HEAD..
does the trick for to review what got added _and_ merged into my local branch. I can't use this for other local branches not checked out. And as I normally want to merge, your suggested behaviour is fine with me *IFF* it is configurable _per_ branch.
Show 14 quoted lines
>> I often do something like this, just to see what got changed. So at least >> in my opinion you have to add a third point: >> * the branch has no modifications what so ever >> * the branch is set up to auto-merge with the particular branch >> fetched from the particular remote >> AND >> * the user set a config option to always autofastfoward if the above >> conditions are true! This could be implemented as a global option with >> a per branch overwrite. > > I'd be fine with that, except I think it's fairly dangerous to have > different defaults. The two first points are sort of the core of the > case I've been arguing all along. >
I aggree. And thats why I think your autofastforward should be set to "false" per default, so that the distinction between local and remote branches would still be clearly defined. Changing this would confuse new users a lot more, me thinks.
But having the option for power users sounds fine!
Show 12 quoted lines
>> Only if this option is added so a user can mark a branch to never >> autofastforward (but it is still possible to have an auto-merge config) >> you won't >> loose valuable information. > > Sure. I was thinking something along these lines: > > [branch "foo"] > remote = bar > merge = some-branch > autofastforward = false >
Thats exactlcy what I had in mind. Maybe and a
[core] global_autofastforward = true
so you could have a sane default for every branch which is missing the autofastforward statement. (or make it per [remote "foo"] ?)
Show 5 quoted lines
> Or use git-fetch. git-pull is "fetch + merge". Conceptually, I don't > think it'll be any problem what so ever telling anyone that the branches > that aren't currently checked out get merged automatically only if they > result in a fast-forward. >
I'm not so sure about that.
-Peter