* Re: Howto request: going home in the middle of something?
From: Jing Xue @ 2007-10-24 13:44 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Jan Wielemaker, Petr Baudis, git
In-Reply-To: <256C87B5-3ADE-4A96-9530-A45B97601BAA@spinlock.ch>
On Tue, Oct 23, 2007 at 10:28:46PM +0200, Matthias Kestenholz wrote:
> Hi,
Hi,
> If someone tracks the main branch you are working on and fetches
> while you are travelling home, he has the WIP commit as a new tip
> in his tree.
> If he bases further work upon the WIP commit, he'll need to rebase
> or merge his changes onto your new tip once you have amended or
> replaced the commit. If you are working on the
> master branch, you should really avoid rewinding it. Rewinding topic
> branches is ok, but a temporary branch is still better to clearly tell
> potential fetch-ers that this is only Work in Progress, and not meant
> to be published in the current state.
Good point. Although I guess if some workflow lets you directly hack on a
public branch, it can have lots of other issues beyond just the WIP
being pulled accidentally, no?
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Scott Parish @ 2007-10-24 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzly84qwf.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 24, 2007 at 05:51:28AM -0700, Junio C Hamano wrote:
> * js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit
> - execv_git_cmd(): also try PATH if everything else fails.
>
> I do not quite get why this is needed; need to go back to the
> discussion myself. On the other hand, I found the alternative
> approach suggested on the list very interesting (i.e. instead of
> "also try", just letting exec*p use PATH, relying on the fact
> that we do prepend-to-path anyway). What happened to it? Was
> there a downside?
The main downside that was raised was MingW compatibility, but
Schindelin and Sixt both said that it could wait until further
work is done porting to MingW.
Should i resend my string of patches? I've seen people numbering
their patches, should i do that as well?
Thanks
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: UI and git-completion.sh
From: Pierre Habouzit @ 2007-10-24 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710241113190.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
On Wed, Oct 24, 2007 at 10:20:07AM +0000, Johannes Schindelin wrote:
> BTW Pierre's idea of generating many (if not all) of these completions on
> the fly (maybe with "--help-completion"?) is intriguing.
To be fair, it's not my idea, I'm just bought to it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Recover a stash
From: Medve Emilian-EMMEDVE1 @ 2007-10-24 17:26 UTC (permalink / raw)
To: git
Hello,
Is there any way to recover a stash as a... stash? I accidently removed
a stash I still need and I'd like to recover it as a stash. I can see
the dangling commit objects in the database with git lost-found and I
can have a branch/head point at them, but it's not understood as stash
anymore.
Thank you,
Emil.
^ permalink raw reply
* Re: Recover a stash
From: Johannes Schindelin @ 2007-10-24 17:42 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27016E5841@az33exm24.fsl.freescale.net>
Hi,
On Wed, 24 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
> Is there any way to recover a stash as a... stash? I accidently removed
> a stash I still need and I'd like to recover it as a stash. I can see
> the dangling commit objects in the database with git lost-found and I
> can have a branch/head point at them, but it's not understood as stash
> anymore.
You should be able to recover it with
git update-ref refs/stash <commit>
Where the <commit> points to the merge commit of the stashed index and the
stashed working directory.
Hth,
Dscho
^ permalink raw reply
* Re: UI and git-completion.sh
From: Johannes Gilger @ 2007-10-24 17:34 UTC (permalink / raw)
To: git
In-Reply-To: <86ve8x9z1f.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
> Where is it? I'm a zsh user, and would love to have git support.
>
Another way to get git-completion support with zsh (works with 4.3.2) is to use
the existing bash-completion and enable bash-completion for zsh via:
autoload bashcompinit
bashcompinit
in your .zshrc or similar. Btw, if you use gentoo you can install git with bash-completion,
although i suppose that most people here are not using emerge to get their git ;).
Greetings,
Johannes
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-10-24 18:27 UTC (permalink / raw)
To: Scott Parish; +Cc: Junio C Hamano, git
In-Reply-To: <20071024160852.GA759@srparish.net>
Scott Parish wrote:
> On Wed, Oct 24, 2007 at 05:51:28AM -0700, Junio C Hamano wrote:
>
>> * js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit
>> - execv_git_cmd(): also try PATH if everything else fails.
>>
>> I do not quite get why this is needed; need to go back to the
>> discussion myself. On the other hand, I found the alternative
>> approach suggested on the list very interesting (i.e. instead of
>> "also try", just letting exec*p use PATH, relying on the fact
>> that we do prepend-to-path anyway). What happened to it? Was
>> there a downside?
>
> The main downside that was raised was MingW compatibility, but
> Schindelin and Sixt both said that it could wait until further
> work is done porting to MingW.
>
> Should i resend my string of patches? I've seen people numbering
> their patches, should i do that as well?
>
'git format-patch -n' will do it for you. I take it you've found
out about git-send-email already?
--
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 18:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Andreas Ericsson, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710231155321.25221@racer.site>
On Oct 23, 2007, at 12:58 PM, Johannes Schindelin wrote:
> On Tue, 23 Oct 2007, Steffen Prohaska wrote:
>
>>
>> On Oct 23, 2007, at 1:35 AM, Jakub Narebski wrote:
>>
>>> 2. Git can do a merge with conflicts _only_ if that branch is
>>> checked
>>> out.
>>
>> Andreas' proposal contains an important requirement that avoids this
>> problem. His proposal states "when they, prior to fetching,
>> pointed to
>> the same commit [the head in remotes pointed to]". That is only
>> fast-forwards are needed, which never have merge conflicts.
>
> You know what I do not like with this proposal? The whole _point_
> of this
> discussion is to make git _easier_. Go ahead, try to explain to a
> complete git newbie the proposed behaviour. I have a pound here which
> says that there is _no_ _way_ that this newbie says "well, that's
> easy".
>
> Some people may not get this, but git has a reputation of being
> complicated, and my "BS" argument was, is, and will be, that we should
> keep clear and simple semantics, because they are the _only_ way to
> battle
> that reputation.
I try to explain the workflow that I'd use the feature for.
Maybe an easier setup could be used to achieve the same.
Any suggestions for a simpler setup are welcome.
The workflow is used by a group of developers that all have
access to a shared repository. One major goal is to keep the
setup for most developers simple. They are new to git and
as few commands as possible should be sufficient to start
working. Besides the typical stable branches (master, next)
shared topic branches should be available that can be used
to develop and review features before they are merged to the
stable branches. Patches are not send by email.
So here's the setup:
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.
This is absolutely stupid. Therefore the developer starts
to hate git, or she just starts to ignore the errors because
they don't have a real meaning most of the times. And later,
when the error could be helpful she would ignore it, too.
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.
I see two reasonable solutions:
1) "git push" only pushes the current branch.
2) "git pull" pulls all branches as proposed by Andreas.
Maybe something that I don't see is fundamentally wrong with
the setup.
Johannes, you mentioned that it is essential to distinguish
remote branches from local branches. In general, I agree. The
problem described above is 'smaller' if you have less local
branches that you're not actively working on. But I believe
it is reasonable to have more than one of them. The remotes
track everything and your local branches are a subset of things
you're interested in although you're not working on each of
the branch every day. I don't think it's reasonable to delete
a local branch immediately each time you stopped working on it.
I think root of the problem is that git is more focused on
pulling from read-only and pushing to non-shared repos. The
support for shared repos needs to be improved before it
is perfect.
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 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
* 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: 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: 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
* 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: 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
* 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: 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: [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: 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: 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: 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: 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: 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: [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: 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: 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
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