* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-24 22:51 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Peter Baumann, Andreas Ericsson,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071024223815.GN29830@fieldses.org>
On Oct 25, 2007, at 12:38 AM, J. Bruce Fields wrote:
> On Thu, Oct 25, 2007 at 12:33:37AM +0200, Steffen Prohaska wrote:
>> Maybe. I know git quite well now and in a shared workflow "git pull"
>> with auto-fast-forward would help me. I often need to run "for each
>> local branch: git checkout ; git merge" to get rid of the errors
>> reported by "git push".
>
> Hm. There's gotta be more efficient ways to do that. Maybe "git
> push .
> origin/branch:branch" for each local "branch"?
>
> But I'm still a little confused why you don't just want to "git push
> name-of-branch" and avoid the whole problem.
There are two points:
- The current implementation of "git push" creates a remote branch
if it does not yet exist. I want a safety net: "git push" only pushes
if the remote branch already exists. In a sense "git push" is safer
than "git push branch-with-typo". I use "git push branchname"
exclusively for _creating_ new branches on the remote.
- Sometimes I updated two local branches and want to push. "git push"
just works.
I started to believe that "git push" should always do the right
thing. Maybe it is not possible, but actually "git push" always
does the right thing for me if I ignore the error messages
about local branches that need merging. I tend to merge all
such branches right away, although it is a bit of a hassel.
Otherwise, there will be a day I'll miss an important error.
What concerns me more is how to explain the behaviour to others.
Right now, I can't tell them that "git push" just works but need
to go into a lot of details.
Steffen
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-24 22:38 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Peter Baumann, Andreas Ericsson,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <008A7EF9-6F58-47AE-9AA0-B466797F6B1D@zib.de>
On Thu, Oct 25, 2007 at 12:33:37AM +0200, Steffen Prohaska wrote:
> Maybe. I know git quite well now and in a shared workflow "git pull"
> with auto-fast-forward would help me. I often need to run "for each
> local branch: git checkout ; git merge" to get rid of the errors
> reported by "git push".
Hm. There's gotta be more efficient ways to do that. Maybe "git push .
origin/branch:branch" for each local "branch"?
But I'm still a little confused why you don't just want to "git push
name-of-branch" and avoid the whole problem.
--b.
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-24 22:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Peter Baumann, Andreas Ericsson, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710242258201.25221@racer.site>
On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
> And here I have to disagree strongly. In a workflow based on a shared
> repository, you do not want to merge. You want to rebase. First
> thing
> you do when switching to another branch is fetch + rebase (that's
> why I
> want an option to "pull --rebase" other branches).
>
> But _even if_ you merge instead of rebase, I fail to see how the
> current
> situation is different from CVS (which many people maintain is
> _easier_
> than gi), where first thing you do is to "cvs update". Just for
> git it is
> "git pull".
>
> But I think I have to drive my message home again: if what you desire
> becomes reality, you take away the clear distinction between local
> and remote branches. In fact, those branches are neither local
> (because
> the next pull will automatically update them with remote changes, but
> _only_ if they fast-forward) nor remote (because you plan to work
> on them
> locally).
Exactly, because I do not work on those branches alone. These
are _shared_ branches. I can work on such a branch with a
group of developers. I'm willing to accept this bit of chaos.
Your rebase workflow is not possible if more than one dev wants
to work on the topic branch together.
Eventually you can linearize such a topic branch using rebase.
But you need to agree first that everyone else needs to delete
the branch.
> But here is a proposal which should make you and your developers
> happy,
> _and_ should be even easier to explain:
>
> Work with topic branches. And when you're done, delete them.
Again, if you want to share the topic branch the situation gets
more complex.
I absolutely agree that for purely local work topic branches that
are deleted before pushing are a good solution.
> So the beginning of the day could look like this:
>
> git fetch
> git checkout -b todays-topic origin/master
>
> [hack hack hack]
> [test test test]
> [debug debug debug]
> [occasionally commit]
> [occasionally git rebase -i origin/master]
>
> and the end of the topic
>
> git branch -M master
> git push origin master
>
> If you should not be ready to push by the end of the day, no need to
> worry. Just stay on that topic branch, and before pushing, do
>
> git fetch
> git rebase origin/master
>
> In _every_ case where I explained git, I found that people
> appreciated the
> two-step procedures (like you will find in the examples I showed you
> above): one git command to work locally, and one to push/fetch to/from
> origin.
Maybe. I know git quite well now and in a shared workflow "git pull"
with auto-fast-forward would help me. I often need to run "for each
local branch: git checkout ; git merge" to get rid of the errors
reported by "git push".
Steffen
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-24 22:17 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Peter Baumann, J. Bruce Fields, Steffen Prohaska, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <471FBF29.8030802@op5.se>
Hi,
On Wed, 24 Oct 2007, Andreas Ericsson wrote:
> 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.
It would be a matter of seconds until someone asks "why only
fast-forwards? Would it not be _much_ better to merge _always_? Stupid
git."
And all because the concept of "local" vs "remote" was blurred.
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-24 22:14 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Peter Baumann, Andreas Ericsson, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <05B279A2-98A3-45F1-9661-AB361F7CAA37@zib.de>
Hi,
On Wed, 24 Oct 2007, Steffen Prohaska wrote:
> On Oct 24, 2007, at 11:28 PM, Peter Baumann wrote:
>
> > 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"?
I am more concerned about having very fuzzy meanings of our nomenclature.
As of now, "pull = fetch + merge". You want to change that, and I am sure
that it is harder to explain, Andreas' insistence on my being wrong
notwithstanding.
Whenever I told people "pull = fetch + merge", they got it. Often I would
start a talk about git by introducing distributed development. By stating
that working in a working directory is already forking, only without
commiting. Then I'd go into details, by saying that there are multiple
repositories, and that you can update local copies of the remote branches
by "git fetch". And you can merge by "git merge". And then I would write
down on the blackboard -- the first written thing in my talk! -- pull =
fetch + merge.
My "pupils" _always_ liked the preciseness of the nomenclature. And they
made many less mistakes because they had a clear mental model of what is
remote, and what is local. And that local branches are always forks.
> > 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.
And here I have to disagree strongly. In a workflow based on a shared
repository, you do not want to merge. You want to rebase. First thing
you do when switching to another branch is fetch + rebase (that's why I
want an option to "pull --rebase" other branches).
But _even if_ you merge instead of rebase, I fail to see how the current
situation is different from CVS (which many people maintain is _easier_
than gi), where first thing you do is to "cvs update". Just for git it is
"git pull".
But I think I have to drive my message home again: if what you desire
becomes reality, you take away the clear distinction between local
and remote branches. In fact, those branches are neither local (because
the next pull will automatically update them with remote changes, but
_only_ if they fast-forward) nor remote (because you plan to work on them
locally).
But here is a proposal which should make you and your developers happy,
_and_ should be even easier to explain:
Work with topic branches. And when you're done, delete them.
So the beginning of the day could look like this:
git fetch
git checkout -b todays-topic origin/master
[hack hack hack]
[test test test]
[debug debug debug]
[occasionally commit]
[occasionally git rebase -i origin/master]
and the end of the topic
git branch -M master
git push origin master
If you should not be ready to push by the end of the day, no need to
worry. Just stay on that topic branch, and before pushing, do
git fetch
git rebase origin/master
In _every_ case where I explained git, I found that people appreciated the
two-step procedures (like you will find in the examples I showed you
above): one git command to work locally, and one to push/fetch to/from
origin.
Ciao,
Dscho
^ permalink raw reply
* Feature request: Limit git-status reports to a directory
From: Michel Marti @ 2007-10-24 22:01 UTC (permalink / raw)
To: git
I am sometimes interested in only seeing the status for a specific
directory (and its sub-directories), but git-status is no help in this
case - passing a directory does some sort of "git-commit --dry-run". I
first thought that this is a bug until I saw in the man-page that this
is actually a feature...
What I would like to have is something like "git status --limit <path>"
and the reported filenames should then be relative to the current
directory for easier copy/pasting them to e.g. git-add, git-diff, etc.
Cheers,
- Michel
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-24 21:54 UTC (permalink / raw)
To: Peter Baumann
Cc: J. Bruce Fields, Steffen Prohaska, Johannes Schindelin,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071024212854.GB6069@xp.machine.xx>
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.
> 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.
> 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
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-24 21:47 UTC (permalink / raw)
To: Peter Baumann
Cc: Andreas Ericsson, J. Bruce Fields, Johannes Schindelin,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071024212854.GB6069@xp.machine.xx>
On Oct 24, 2007, at 11:28 PM, 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
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"?
> 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
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Peter Baumann @ 2007-10-24 21:28 UTC (permalink / raw)
To: Andreas Ericsson
Cc: J. Bruce Fields, Steffen Prohaska, Johannes Schindelin,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <471FB3D0.4040800@op5.se>
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
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.
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.
-Peter
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-24 21:20 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Steffen Prohaska, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <471FB3D0.4040800@op5.se>
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.
The downsides are that it makes the behavior of pull slightly more
complicated, and that it changes long-established default behavior of a
major subcommand. (Those aren't huge disadvantages, but they are
disadvantages.)
>
>> - the user has one or more unmodified copies of remote branches
>> lying around, and
>
> Extremely common case for a large group of users.
OK, but that was one part of a four-"and" clause. I don't see any
absolute clincher here, but on balance I think the disadvantages win
out.
--b.
^ permalink raw reply
* Re: [PATCH] git-send-email: add a new sendemail.to configuration variable
From: Miklos Vajna @ 2007-10-24 21:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191242562-27486-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
Hello,
On Mon, Oct 01, 2007 at 02:42:42PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Several projects prefers to receive patches via a given email address. In these
> cases it's handy to configure that address once.
I'm just replying again to this patch, I think it was forgotten in the
recent flurry of patches... :)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-24 21:16 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Andreas Ericsson, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <20071024203335.GJ29830@fieldses.org>
On Oct 24, 2007, at 10:33 PM, 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).
Personally, I don't dare to work that way. But if you do want
to keep local changes on branches that would normally be pushed
but you do not want to push them now, you must not call "git
push" without arguments in the first place. Then you'll never
see the error emitted by push.
I put local changes that I do not intend to change right away
on a special branch for/<branch>. I only merge them to <branch>
if I decided to push them, and then I push them soon (maybe
after I prepared more branches and then push all at once).
> So the case where this proposal helps is the case where:
> - the user hasn't learned how to name individual branches on the
> push commandline, or has learned to do so, but wants less
> typing, and
Well, as I wrote above "git push" is a too sharp knife for
me. I _never_ have local changes that I don't intend to push.
So "git push" always does the right thing for me.
> - the user has one or more unmodified copies of remote branches
> lying around, and
> - the user minds being reminded that those copies are out of
> date, and
> - the user either has no *modified* copies of local branches, or
> has some but doesn't mind being reminded that they're out of
> date on each push.
I see your point. These are may requirements to make the
proposed behaviour of "git pull" useful. But I'd recommend to
use git exactly as you described when working with a shared
repository:
Just use "git pull" and "git push" and everything will be fine
if you work as follows:
- Use the same branch names that are used on the origin.
- Only check out branches locally that you are especially interested in.
- Only put changes on those branches if you intend to push them.
- Use "git pull" before you start to prepare branches for
"git push".
- Keep you privat work on branches that are named differently
from branches in the shared repository.
Steffen
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-24 21:06 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Steffen Prohaska, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <20071024203335.GJ29830@fieldses.org>
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.
> - the user has one or more unmodified copies of remote branches
> lying around, and
Extremely common case for a large group of users. The worst part is
that this problem can get extremely annoying pretty quickly, with a
large number of repos and a large number of branches, whereas the
one dev per repo folks will never have big worries about it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-remote: Use of uninitialized value in string ne, line 248
From: Ralf Wildenhues @ 2007-10-24 20:40 UTC (permalink / raw)
To: martin f krafft; +Cc: Alex Riesen, Junio C Hamano, git discussion list
In-Reply-To: <20071024202724.GA2292@piper.oerlikon.madduck.net>
* martin f krafft wrote on Wed, Oct 24, 2007 at 10:27:24PM CEST:
>
> perl -e 'print "The earth is a disk!\n" if ( "earth" == "flat" );'
Well, numerical equality and string equality are two different things,
try eq instead (see: perldoc perlop).
> Is there a way to make it explicit that you're checking for a value
> being defined, where a "false" value would count as true, just as
> long as there is a value?
Yes. It's called "defined".
perl -e 'my $a=0; print "yes\n" if defined $a;'
It should be used here, to allow "0" branches.
Cheers,
Ralf
^ permalink raw reply
* Re: git-remote: Use of uninitialized value in string ne, line 248
From: Pierre Habouzit @ 2007-10-24 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: martin f krafft, git discussion list
In-Reply-To: <7vwstc68bk.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
On Wed, Oct 24, 2007 at 11:49:51AM +0000, Junio C Hamano wrote:
> martin f krafft <madduck@madduck.net> writes:
>
> > piper:~> git remote show origin
> > * remote origin
> > URL: ssh://git.madduck.net/~/git/etc/mailplate.git
> > Use of uninitialized value in string ne at /usr/local/stow/git/bin/git-remote line 248.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Perhaps....
>
> git-remote.perl | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-remote.perl b/git-remote.perl
> index 9ca3e7e..4cee044 100755
> --- a/git-remote.perl
> +++ b/git-remote.perl
> @@ -244,7 +244,8 @@ sub show_remote {
> print "* remote $name\n";
> print " URL: $info->{'URL'}\n";
> for my $branchname (sort keys %$branch) {
> - next if ($branch->{$branchname}{'REMOTE'} ne $name);
> + next if (!$branch->{$branchname}{'REMOTE'} ||
> + $branch->{$branchname}{'REMOTE'} ne $name);
This looks better (wrt the "0" issue raised earlier):
+ next unless (defined($branch->{$branchname}{'REMOTE'}) &&
+ $branch->{$branchname}{'REMOTE'} eq $name);
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-24 20:33 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Andreas Ericsson, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <86784BB7-076F-4504-BCE6-4580A7C68AAC@zib.de>
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).
So the case where this proposal helps is the case where:
- the user hasn't learned how to name individual branches on the
push commandline, or has learned to do so, but wants less
typing, and
- the user has one or more unmodified copies of remote branches
lying around, and
- the user minds being reminded that those copies are out of
date, and
- the user either has no *modified* copies of local branches, or
has some but doesn't mind being reminded that they're out of
date on each push.
--b.
^ permalink raw reply
* Re: [PATCH] Add some fancy colors in the test library when terminal supports it.
From: Pierre Habouzit @ 2007-10-24 20:28 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1193256219-24222-2-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
> +default_color=0
> +fail_color=1 # red
> +pass_color=2 # green
> +msg_color=3 # brown
> +
err, sorry, this part is spurious, I wasn't paying attention when I
re-read my patch. It's impressive how many mistakes you catch reading
the same patch 20 minutes later…
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-remote: Use of uninitialized value in string ne, line 248
From: martin f krafft @ 2007-10-24 20:27 UTC (permalink / raw)
To: Alex Riesen, Junio C Hamano, git discussion list
In-Reply-To: <20071024193954.GA5280@steel.home>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
also sprach Alex Riesen <raa.lkml@gmail.com> [2007.10.24.2139 +0200]:
> just you never call yor branches "0".
Wow, Perl is weird. :)
perl -e 'print "The earth is a disk!\n" if ( "earth" == "flat" );'
Is there a way to make it explicit that you're checking for a value
being defined, where a "false" value would count as true, just as
long as there is a value?
--
martin | http://madduck.net/ | http://two.sentenc.es/
micro$oft dns service terminates abnormally
when it receives a response
to a dns query that was never made.
fix information: run your dns service on a different platform.
-- bugtraq
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-24 20:13 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Steffen Prohaska, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <20071024194849.GH29830@fieldses.org>
J. Bruce Fields wrote:
> On Wed, Oct 24, 2007 at 09:41:05PM +0200, Andreas Ericsson wrote:
>> J. Bruce Fields wrote:
>>> On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:
>>>> The central shared repo is called project-shared.git and contains,
>>>> for example, the following branches:
>>>> master
>>>> next
>>>> work/topicA
>>>> work/topicB
>>>> ...
>>>>
>>>>
>>>> Developers clone the repo and check out the branches they are
>>>> interested in. For example a developer may want to track next
>>>> and work on topicB:
>>>>
>>>> git clone ssh://central.example.com/project-shared.git project
>>>> cd project
>>>> git checkout -b next origin/next
>>>> git checkout -b work/topicB origin/work/topicB
>>>>
>>>> This is sufficient. No adding of remotes is needed. Neither
>>>> is a private repository on a server required. After cloning,
>>>> developers have all they need.
>>>>
>>>> Later work/topicB has new commits and should be pushed:
>>>>
>>>> git push origin
>>>>
>>>> The default behaviour of push is fine. Only matching branches
>>>> are pushed.
>>>>
>>>> _But_, origin is a shared repository. Therefore branches may
>>>> have advanced and git push may report
>>>>
>>>> error: remote 'refs/heads/next' is not a strict subset of local ref
>>>> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?
>>>>
>>>> So here's the problem. The developer didn't do anything wrong.
>>>> But git complaints with an error. Git also recommends to run
>>>> pull, so the developer runs "git pull". But this doesn't help,
>>>> because it's only updating work/topicB and "git push" will
>>>> complain with the very same error.
>>>>
>>>> What you need to do is
>>>>
>>>> git checkout <local-branch>
>>>> git pull
>>>> git checkout <local-branch2>
>>>> git pull
>>>> ...
>>>>
>>>> for every local branch.
>>> Or just
>>> git push origin work/topicB
>>> since that's all you really wanted to push anyway.
>> git pull. Not git push. git pull operates on one working branch
>> at a time (by default), whereas git push uploads and fast-forwards
>> all the common branches (by default).
>
> I understand. I was just suggesting that if the goal was to avoid the
> error message on push, then specifying the branch to push explicitly
> would be a solution.
>
A better way to avoid that error message is ofcourse to make sure one
always starts development off of the latest version of the particular
branch one wants to work on.
>> 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).
For a corporate environment with multiple modules, the scenario where the
upstream is modified and the local branches aren't is more common than
anything else. The failure on push happens because developers do
git pull; # Yup, gotta do that to get the latest changes
git checkout whatever; # Here's where I want to work
work work work
git push; # ach crivens! bloody stupid git of a tool to ALWAYS BREAK!
> In other cases the "git push" will still emit a
> spurious error.
>
If the tool can make it happen as few times as possible, that's good
enough for me. It's a lot easier to explain to my co-workers that
their push failed because someone else worked on it simultaneously
and pushed before they did, rather than telling them that they did
the pull/checkout sequence in the wrong order.
In the one scenario, it's "oh, I see". In the other, it's "god damn
piece of shit tool". Simple as that.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-24 20:12 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Andreas Ericsson, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <20071024194849.GH29830@fieldses.org>
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. Then you _have_ local changes that are not at the remote.
You need to handle them somehow. Maybe you forgot to push
earlier and now the remote advanced.
Btw, the 'new' git pull should already have reported a warning
that it failed to fast forward the local branch. git pull
should have suggested to explicitly merge the branch with
local changes.
Steffen
^ permalink raw reply
* Small enhancements of the test-lib.sh
From: Pierre Habouzit @ 2007-10-24 20:03 UTC (permalink / raw)
To: gitster; +Cc: git
Here is a 2-patch series to enhance the test-suite so that the flood
is easier to follow to the eye.
The first patch is a rework of the previous one I sent, and implements
suggestions that were made to me.
The second add a --quiet option that basically stops the flood about
all the test that just pass, and only let the name of the master
t####foo.sh script be printed, and the summary of its test (and the
occasional spurious outputs the testsuite does).
This "series" is available as ph/testlib on my
git://git.madism.org/git.git
Cheers,
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-24 19:48 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Steffen Prohaska, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <471F9FD1.6080002@op5.se>
On Wed, Oct 24, 2007 at 09:41:05PM +0200, Andreas Ericsson wrote:
> J. Bruce Fields wrote:
>> On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:
>>> The central shared repo is called project-shared.git and contains,
>>> for example, the following branches:
>>> master
>>> next
>>> work/topicA
>>> work/topicB
>>> ...
>>>
>>>
>>> Developers clone the repo and check out the branches they are
>>> interested in. For example a developer may want to track next
>>> and work on topicB:
>>>
>>> git clone ssh://central.example.com/project-shared.git project
>>> cd project
>>> git checkout -b next origin/next
>>> git checkout -b work/topicB origin/work/topicB
>>>
>>> This is sufficient. No adding of remotes is needed. Neither
>>> is a private repository on a server required. After cloning,
>>> developers have all they need.
>>>
>>> Later work/topicB has new commits and should be pushed:
>>>
>>> git push origin
>>>
>>> The default behaviour of push is fine. Only matching branches
>>> are pushed.
>>>
>>> _But_, origin is a shared repository. Therefore branches may
>>> have advanced and git push may report
>>>
>>> error: remote 'refs/heads/next' is not a strict subset of local ref
>>> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?
>>>
>>> So here's the problem. The developer didn't do anything wrong.
>>> But git complaints with an error. Git also recommends to run
>>> pull, so the developer runs "git pull". But this doesn't help,
>>> because it's only updating work/topicB and "git push" will
>>> complain with the very same error.
>>>
>>> What you need to do is
>>>
>>> git checkout <local-branch>
>>> git pull
>>> git checkout <local-branch2>
>>> git pull
>>> ...
>>>
>>> for every local branch.
>> Or just
>> git push origin work/topicB
>> since that's all you really wanted to push anyway.
>
> git pull. Not git push. git pull operates on one working branch
> at a time (by default), whereas git push uploads and fast-forwards
> all the common branches (by default).
I understand. I was just suggesting that if the goal was to avoid the
error message on push, then specifying the branch to push explicitly
would be a solution.
> 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.
--b.
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-24 19:41 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Steffen Prohaska, Johannes Schindelin, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <20071024192058.GF29830@fieldses.org>
J. Bruce Fields wrote:
> On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:
>> The central shared repo is called project-shared.git and contains,
>> for example, the following branches:
>> master
>> next
>> work/topicA
>> work/topicB
>> ...
>>
>>
>> Developers clone the repo and check out the branches they are
>> interested in. For example a developer may want to track next
>> and work on topicB:
>>
>> git clone ssh://central.example.com/project-shared.git project
>> cd project
>> git checkout -b next origin/next
>> git checkout -b work/topicB origin/work/topicB
>>
>> This is sufficient. No adding of remotes is needed. Neither
>> is a private repository on a server required. After cloning,
>> developers have all they need.
>>
>> Later work/topicB has new commits and should be pushed:
>>
>> git push origin
>>
>> The default behaviour of push is fine. Only matching branches
>> are pushed.
>>
>> _But_, origin is a shared repository. Therefore branches may
>> have advanced and git push may report
>>
>> error: remote 'refs/heads/next' is not a strict subset of local ref
>> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?
>>
>> So here's the problem. The developer didn't do anything wrong.
>> But git complaints with an error. Git also recommends to run
>> pull, so the developer runs "git pull". But this doesn't help,
>> because it's only updating work/topicB and "git push" will
>> complain with the very same error.
>>
>> What you need to do is
>>
>> git checkout <local-branch>
>> git pull
>> git checkout <local-branch2>
>> git pull
>> ...
>>
>> for every local branch.
>
> Or just
>
> git push origin work/topicB
>
> since that's all you really wanted to push anyway.
>
git pull. Not git push. git pull operates on one working branch
at a time (by default), whereas git push uploads and fast-forwards
all the common branches (by default). I want git pull to work like
git push.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-remote: Use of uninitialized value in string ne, line 248
From: Alex Riesen @ 2007-10-24 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
In-Reply-To: <7vwstc68bk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Oct 24, 2007 13:49:51 +0200:
> Perhaps....
>
> git-remote.perl | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-remote.perl b/git-remote.perl
> index 9ca3e7e..4cee044 100755
> --- a/git-remote.perl
> +++ b/git-remote.perl
> @@ -244,7 +244,8 @@ sub show_remote {
> print "* remote $name\n";
> print " URL: $info->{'URL'}\n";
> for my $branchname (sort keys %$branch) {
> - next if ($branch->{$branchname}{'REMOTE'} ne $name);
> + next if (!$branch->{$branchname}{'REMOTE'} ||
just you never call yor branches "0".
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-24 19:20 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Jakub Narebski, Andreas Ericsson,
Federico Mena Quintero, git
In-Reply-To: <90325C2E-9AF4-40FB-9EFB-70B6D0174409@zib.de>
On Wed, Oct 24, 2007 at 08:48:54PM +0200, Steffen Prohaska wrote:
> The central shared repo is called project-shared.git and contains,
> for example, the following branches:
> master
> next
> work/topicA
> work/topicB
> ...
>
>
> Developers clone the repo and check out the branches they are
> interested in. For example a developer may want to track next
> and work on topicB:
>
> git clone ssh://central.example.com/project-shared.git project
> cd project
> git checkout -b next origin/next
> git checkout -b work/topicB origin/work/topicB
>
> This is sufficient. No adding of remotes is needed. Neither
> is a private repository on a server required. After cloning,
> developers have all they need.
>
> Later work/topicB has new commits and should be pushed:
>
> git push origin
>
> The default behaviour of push is fine. Only matching branches
> are pushed.
>
> _But_, origin is a shared repository. Therefore branches may
> have advanced and git push may report
>
> error: remote 'refs/heads/next' is not a strict subset of local ref
> 'refs/heads/next'. maybe you are not up-to-date and need to pull first?
>
> So here's the problem. The developer didn't do anything wrong.
> But git complaints with an error. Git also recommends to run
> pull, so the developer runs "git pull". But this doesn't help,
> because it's only updating work/topicB and "git push" will
> complain with the very same error.
>
> What you need to do is
>
> git checkout <local-branch>
> git pull
> git checkout <local-branch2>
> git pull
> ...
>
> for every local branch.
Or just
git push origin work/topicB
since that's all you really wanted to push anyway.
> The problem described can only happen with a shared repository.
> In a workflow that pulls from read-only repos and pushes to a
> private repo that is read-only for others, such a problem cannot
> happen. Because in a non-shared repository the branches cannot
> be advanced by others. But in a shared repository they can.
Actually I push to my public repo from multiple working repositories
(because usually I work on my laptop, but sometimes I do work from a
different machine), so the above can still happen.
--b.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox