Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
- From
Steffen Prohaska <prohaska@zib.de>
- Date
- Oct 24, 2007, 21:47 UTC
- Message-ID
- <05B279A2-98A3-45F1-9661-AB361F7CAA37@zib.de>
- In-Reply-To
- <20071024212854.GB6069@xp.machine.xx>
On Oct 24, 2007, at 11:28 PM, Peter Baumann wrote:
Show 35 quoted lines
> 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
You're not forced to pull. Just use "git fetch" if you want to do this. Or is something missing if you'd be limited to "git fetch"?
Show 12 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 (and, as I understood, Andreas, too) want to change the default. Because we believe that git would be easier to use in workflows based on a shared repository.
But if we fail to convince the list, maybe a global configuration variable that configures "git pull" to autoforward branches as propose would be a nearly equally good solution.
However, I think it is dangerous to introduce many of such configuration options. Explaining the behaviour of git will become harder. The behaviour will become dependent on the local configuration and eventually the first question before answering a question will be "send me the output of 'git config --list'. I need to see how your git is configured."
Steffen