* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 12:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0711061216330.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2481 bytes --]
On Tue, Nov 06, 2007 at 12:25:33PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > >> In the same way, I would expect "git revert <commit> -- file" to undo the
> > >> changes in that commit to _that_ file (something like "git merge-file
> > >> file <commit>:file <commit>^:file"), but this time commit it, since it
> > >> was committed at one stage.
> > >
> > > Allowing people to revert or cherry pick partially by using
> > > paths limiter is a very good idea; ...
> >
> > As Pierre said earlier, a partial revert via "revert <commit> --
> > <paths>" and a partial cherry-pick would make quite a lot of
> > sense, and in addition, it should not be too hard to add.
>
> Yes, but Pierre also said earlier that people want to revert their local
> changes. And the logical thing to try that really is
>
> git revert <path>
>
> Now, if you read that out in English, it does not make too much sense:
> "revert the path" (not "revert the _changes_ to that file"). But it is
> what people try to do.
>
> However, IIUC another thing Pierre mentioned is that
>
> $scm revert <commit> <path>
>
> commonly means "revert the file _to the version_ stored in <commit>".
> This is just different enough from "revert the _changes_ to that file
> stored in <commit>" to bite people, no?
Yeah but that's what checkout is for. The main source of iritation for
new users comes (IMHO) from svn, where `svn revert path/to/file` is part
of the workflow: in case of a conflict when you `svn up`, you have
either to:
(1) fix the conflict and `svn resolved path/to/file`
(2) drop your changes and take the trunk version `svn revert path/to/file`
People really expect git revert -- path/to/file to do the same as git
checkout HEAD -- path/to/file. Though I believe that like I said, maybe
we don't wan't git revert -- path/to/file to become the first class
command to do that, but rather to do what the user meant, hinting him in
the direction of the proper command. I wasn't really advocating that
git-revert should be a complete implementation of what git checkout
<comitish> -- <paths> does. YMMV.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-merge ignore specific files
From: Bill Priest @ 2007-11-06 12:38 UTC (permalink / raw)
To: git
All,
I have two branches that are slightly different and
most changes "belong" in both. There are a handful of
files/directories that are disparate. Is there any
way in git to tell it not to merge these files? Kind
of like .gitignore but for merges.
In addition I'd like a way to specify to git-merge
to leave all merged files unrecorded in the index.
Then as I go through each file making sure that the
merge "makes sense" (not that git did the right thing;
but that I want the changes in both branches) that I
add the change to the index.
I'm sure that I'm probably using git "incorrectly"
and I welcome suggestions for modifying my workflow to
a git style.
Any and all suggestions greatly appreciated,
Bill
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vode8j7o5.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 5 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> >
> >> Allowing people to revert or cherry pick partially by using paths
> >> limiter is a very good idea; the whole "it comes from a commit so we
> >> also commit" feels an utter nonsense, though.
> >
> > No.
> >
> > When "git revert <commit>" commits the result, "git revert <commit> --
> > <file>" should, too.
>
> I was not questioning about that part. "If 'git revert <some
> other form> foo' does not talk about commit, it should not
> commit" was what I was referring to.
Well, I think that _if_ we allow "git revert <path>" to mean "revert the
changes to <path>, relative to the index" (which would be the same as "git
checkout <path>"), then committing that change just does not make sense.
And it is this behaviour that people are seeking, not "git revert <commit>
<path>".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vk5oviqbe.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> In the same way, I would expect "git revert <commit> -- file" to undo the
> >> changes in that commit to _that_ file (something like "git merge-file
> >> file <commit>:file <commit>^:file"), but this time commit it, since it
> >> was committed at one stage.
> >
> > Allowing people to revert or cherry pick partially by using
> > paths limiter is a very good idea; ...
>
> As Pierre said earlier, a partial revert via "revert <commit> --
> <paths>" and a partial cherry-pick would make quite a lot of
> sense, and in addition, it should not be too hard to add.
Yes, but Pierre also said earlier that people want to revert their local
changes. And the logical thing to try that really is
git revert <path>
Now, if you read that out in English, it does not make too much sense:
"revert the path" (not "revert the _changes_ to that file"). But it is
what people try to do.
However, IIUC another thing Pierre mentioned is that
$scm revert <commit> <path>
commonly means "revert the file _to the version_ stored in <commit>".
This is just different enough from "revert the _changes_ to that file
stored in <commit>" to bite people, no?
> Reusing the 'merge-recursive' part should be almost trivial. The only
> tricky part is coming up with a fake tree using base and next commit in
> revert_or_cherry_pick() for this purpose.
FWIW I really wanted to use the merge-file machinery, not the
merge-recursive one. But since "<path>" can be a directory, too, I was
mistaken, and you are correct, as always.
> As to "reverting to the index" case, if somebody is interested in doing
> a builtin-checkout.c, please keep in mind that major parts of that work
> should be made available to the implementation of "git revert [--]
> <paths>", as it appears that it will be exactly the same as "git
> checkout" with the same set of options.
I was planning to put cmd_checkout() into builtin-reset.c for that reason.
But first things first, that "git remote prune" with --mirror'ed
repositories misbehaviour annoys me just enough that I started converting
this script first. It has been stable enough for quite a long time, and
the script now shows its limitations.
Besides, remote.[ch] makes it easy, even if not _really_ easy.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Schindelin @ 2007-11-06 12:16 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Steven Grimm, Pierre Habouzit, Git Mailing List
In-Reply-To: <47305536.5010308@viscovery.net>
Hi,
On Tue, 6 Nov 2007, Johannes Sixt wrote:
> Junio C Hamano schrieb:
> > I am wondering what "git cherry-pick -- <paths>" should do. My
> > current thinking is that it would not make any sense at all.
>
> IMO, at least "git cherry-pick -n -- <paths>" makes tons of sense.
I guess you missed that Junio did not specify any commit. With a commit,
I agree, it makes tons of sense.
Without a commit, it would default to... uhm... HEAD? And applying the
changes to a given file, which are already in HEAD, no, that does not make
sense.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Andreas Ericsson @ 2007-11-06 12:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <Pine.LNX.4.64.0711061204160.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Tue, 6 Nov 2007, Andreas Ericsson wrote:
>>>
>>>> Bill Lear wrote:
>>>>> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
>>>>>> Aghiles <aghilesk@gmail.com> writes:
>>>>>>
>>>>>>> Is there an "easier" way to pull into a dirty directory ? I am
>>>>>>> asking this to make sure I understand the problem and not
>>>>>>> because I find it annoying to type those 4 commands to perform
>>>>>>> a pull (although some of my colleagues do find that annoying :).
>>>>>> You need to switch your mindset from centralized SVN workflow.
>>>>>>
>>>>>> The beauty of distributedness is that it redefines the meaning
>>>>>> of "to commit". In distributed systems, the act of committing
>>>>>> is purely checkpointing and it is not associated with publishing
>>>>>> the result to others as centralized systems force you to.
>>>>>>
>>>>>> Stop thinking like "I need to integrate the changes from
>>>>>> upstream into my WIP to keep up to date." You first finish what
>>>>>> you are currently doing, at least to the point that it is
>>>>>> stable, make a commit to mark that state, and then start
>>>>>> thinking about what other people did. You may most likely do a
>>>>>> "git fetch" followed by "git rebase" to update your WIP on top
>>>>>> of the updated work by others.
>>>>>>
>>>>>> Once you get used to that, you would not have "a dirty
>>>>>> directory" problem.
>>>>> I respectfully beg to differ. I think it is entirely reasonable, and
>>>>> not a sign of "centralized" mindset, to want to pull changes others
>>>>> have made into your dirty repository with a single command.
>>>>>
>>>> I find it much more convenient to just fetch them. I'd rather see
>>>> git-pull being given a --rebase option (which would ultimately mean
>>>> teaching git-merge about it) to rebase already committed changes on
>>>> top of the newly fetched tracking branch. It's being worked on, but
>>>> rather slowly.
>>> git-pull learning about --rebase does not mean teaching git-merge about it.
>>> See my patch, which you (and others) failed to enthusiastically embrace,
>>> which is the sole reason it is stalled.
>>>
>> I must have missed it. Found the thread now though. Gonna try the patch in
>> production for a while and see how it pans out.
>>
>> I'm curious about this hunk though. It seems unaffiliated with the --rebase
>> option as such, but was still in the patch. Would you care to clarify?
>>
>> @@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
>>
>> case "$merge_head" in
>> '')
>> - curr_branch=$(git symbolic-ref -q HEAD)
>> case $? in
>> 0) ;;
>> 1) echo >&2 "You are not currently on a branch; you must
>> explicitly"
>>
>
> No, it is not unaffiliated. If you go back to the patch, you will find
> that this line was not deleted, but moved to the start of git-rebase.sh.
> We need to know the branch name to get the config settings, and might just
> as well reuse the branch name for the merge_head case.
>
Righto. I should learn to not write emails or read patches before 10am.
Thanks for clarifying.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 12:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <47302D07.9030703@op5.se>
Hi,
On Tue, 6 Nov 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 6 Nov 2007, Andreas Ericsson wrote:
> >
> > > Bill Lear wrote:
> > > > On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
> > > > > Aghiles <aghilesk@gmail.com> writes:
> > > > >
> > > > > > Is there an "easier" way to pull into a dirty directory ? I am
> > > > > > asking this to make sure I understand the problem and not
> > > > > > because I find it annoying to type those 4 commands to perform
> > > > > > a pull (although some of my colleagues do find that annoying :).
> > > > > You need to switch your mindset from centralized SVN workflow.
> > > > >
> > > > > The beauty of distributedness is that it redefines the meaning
> > > > > of "to commit". In distributed systems, the act of committing
> > > > > is purely checkpointing and it is not associated with publishing
> > > > > the result to others as centralized systems force you to.
> > > > >
> > > > > Stop thinking like "I need to integrate the changes from
> > > > > upstream into my WIP to keep up to date." You first finish what
> > > > > you are currently doing, at least to the point that it is
> > > > > stable, make a commit to mark that state, and then start
> > > > > thinking about what other people did. You may most likely do a
> > > > > "git fetch" followed by "git rebase" to update your WIP on top
> > > > > of the updated work by others.
> > > > >
> > > > > Once you get used to that, you would not have "a dirty
> > > > > directory" problem.
> > > > I respectfully beg to differ. I think it is entirely reasonable, and
> > > > not a sign of "centralized" mindset, to want to pull changes others
> > > > have made into your dirty repository with a single command.
> > > >
> > > I find it much more convenient to just fetch them. I'd rather see
> > > git-pull being given a --rebase option (which would ultimately mean
> > > teaching git-merge about it) to rebase already committed changes on
> > > top of the newly fetched tracking branch. It's being worked on, but
> > > rather slowly.
> >
> > git-pull learning about --rebase does not mean teaching git-merge about it.
> > See my patch, which you (and others) failed to enthusiastically embrace,
> > which is the sole reason it is stalled.
> >
>
> I must have missed it. Found the thread now though. Gonna try the patch in
> production for a while and see how it pans out.
>
> I'm curious about this hunk though. It seems unaffiliated with the --rebase
> option as such, but was still in the patch. Would you care to clarify?
>
> @@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
>
> case "$merge_head" in
> '')
> - curr_branch=$(git symbolic-ref -q HEAD)
> case $? in
> 0) ;;
> 1) echo >&2 "You are not currently on a branch; you must
> explicitly"
>
No, it is not unaffiliated. If you go back to the patch, you will find
that this line was not deleted, but moved to the start of git-rebase.sh.
We need to know the branch name to get the config settings, and might just
as well reuse the branch name for the merge_head case.
Hth,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 12:02 UTC (permalink / raw)
To: Aghiles; +Cc: Jakub Narebski, git
In-Reply-To: <3abd05a90711052022j590f1faesb85f4646afd9acec@mail.gmail.com>
Hi,
On Mon, 5 Nov 2007, Aghiles wrote:
> > The consense was that you are much better off committing first, then
> > pulling. And if the work you are doing really is not committable, but
> > you _have_ to pull _now_, you use stash. Although you are quite
> > likely to revert the pull when it succeeds, and _then_ unstash.
>
> Sorry but I don't really understand why one should "revert the pull" ?
> Could elaborate for a newbie ? :)
Yes, no problem.
A pull is just a fetch and a merge. And a merge is a commit with more
than one parent. So you can use the command "git reset --hard HEAD^" to
undo a merge, just as you can undo any other commit.
NOTE: if you pushed that commit (merge or not), do _not_ use reset. This
effectively rewrites history, and _will_ upset people pulling from you.
If you really have to undo a commit you already published, use "git revert
<commit>".
Hth,
Dscho
^ permalink raw reply
* Re: git pull opinion
From: Johannes Schindelin @ 2007-11-06 11:59 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: Benoit Sigoure, Aghiles, git list
In-Reply-To: <20071106073455.GA19106@ins.uni-bonn.de>
Hi,
On Tue, 6 Nov 2007, Ralf Wildenhues wrote:
> * Benoit Sigoure wrote on Tue, Nov 06, 2007 at 06:29:58AM CET:
> > On Nov 6, 2007, at 5:16 AM, Aghiles wrote:
> >
> >>> who will run git stash clear? :)
> >>
> >> Yes you are right. By the way, in the context of merging into a
> >> dirty tree, "git stash clear" seems to be a dangerous command:
> >> there is a risk of loosing all your changes without a question
> >> asked!
>
> I would love it if for once in the git world, there were a pair of
> commands that would do the exact opposite of each other and where the
> naive newbie (me) would immediately recognize that from their names:
> git stash push
> git stash pop
>
> Both applied in this order should be a no-op on both the working tree,
> the index, and also the stash. There's room for extensions (pop
> --keep-stash to not remove the stashed information), explicit naming of
> stashes, doing multiple pops at once, and so on. Please don't add more
> of the git-push/git-pull, git-add/git-rm unsymmetrical interfaces.
> Even if they're perfectly clear to git intimates, each one of them
> takes precious extra time to learn due to this lack of symmetry.
>
> Since I simply don't have the time resources to just implement that,
> I'll thank you for your attention and go back to lurking mode now.
You might as well be honest, and say that they are not time constraints,
but lack of motivation. There is -- still! -- the patch "Teach "git
reflog" a subcommand to delete single entries" in "pu" to delete
single reflogs (and being in "pu" means it is only a fetch and a
cherry-pick away).
Implementing that feature would be a piece of cake, but I will not do it,
since _you_ want it, not _I_. In spite of that, I implemented that reflog
deleting, which was the hardest part of the exercise.
So, out, out with you, out of lurking mode!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Johannes Sixt @ 2007-11-06 11:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Steven Grimm, Pierre Habouzit,
Git Mailing List
In-Reply-To: <7vk5oviqbe.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I am wondering what "git cherry-pick -- <paths>" should do. My
> current thinking is that it would not make any sense at all.
IMO, at least "git cherry-pick -n -- <paths>" makes tons of sense.
-- Hannes
^ permalink raw reply
* Re: [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Francesco Pretto @ 2007-11-06 11:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711061052570.4362@racer.site>
Johannes Schindelin ha scritto:
>
> For most people, neither path is correct.
Yeah, I agree. I'll try to reflect this with a neutral wording :-)
In the context of the documentation, we should just take care of logical
following the example.
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Junio C Hamano @ 2007-11-06 11:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Pierre Habouzit, git
In-Reply-To: <7vsl3kjdct.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> In the same way, I would expect "git revert <commit> -- file" to undo the
>> changes in that commit to _that_ file (something like "git merge-file
>> file <commit>:file <commit>^:file"), but this time commit it, since it
>> was committed at one stage.
>
> Allowing people to revert or cherry pick partially by using
> paths limiter is a very good idea; ...
As Pierre said earlier, a partial revert via "revert <commit> --
<paths>" and a partial cherry-pick would make quite a lot of
sense, and in addition, it should not be too hard to add.
Reusing the 'merge-recursive' part should be almost trivial.
The only tricky part is coming up with a fake tree using base
and next commit in revert_or_cherry_pick() for this purpose.
When replaying the change from A->B (when cherry-picking, A is
the parent and B is what was named from the command line; when
reverting, they are the other way around), instead of doing the
three-way merge using:
merge-recursive A HEAD B
you would first come up with a modified tree B' that has the
identical contents to A _except_ the parts the path limiters
specify which are taken from B. Then running
merge-recursive A HEAD B'
would replay the revert or cherry-pick of change from A->B,
limited by the path, on top of the current HEAD.
As to "reverting to the index" case, if somebody is interested
in doing a builtin-checkout.c, please keep in mind that major
parts of that work should be made available to the
implementation of "git revert [--] <paths>", as it appears that
it will be exactly the same as "git checkout" with the same set
of options.
I am wondering what "git cherry-pick -- <paths>" should do. My
current thinking is that it would not make any sense at all.
^ permalink raw reply
* Re: [PATCH] git-mailsplit: with maildirs try to process new/ if cur/ is empty
From: Johannes Schindelin @ 2007-11-06 11:01 UTC (permalink / raw)
To: Jeff King
Cc: Alex Riesen, Michael Cohen, Gerrit Pape, Fernando J. Pereda, git,
Junio C Hamano
In-Reply-To: <20071106075150.GA21694@sigill.intra.peff.net>
Hi,
On Tue, 6 Nov 2007, Jeff King wrote:
> On Tue, Nov 06, 2007 at 08:28:31AM +0100, Alex Riesen wrote:
>
> > > In Maildir format, cur and new hold the mails. :P
> >
> > So? Why *STOP* reading the mails if just one of the directories could
> > not be opened? IOW, I suggest:
>
> Because you are then trying to apply a patch series with some patches
> potentially missing? Continuing only on errno == ENOENT seems prudent.
I fail to see how the absence of one of cur/ or new/ can lead to the
absence of patches. You could forget to save some patches, yes, but the
presence of cur/ and new/ is no indicator for that.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] When exec() fails include the failing command in the error message
From: Ask Bjørn Hansen @ 2007-11-06 10:54 UTC (permalink / raw)
To: git; +Cc: Ask Bjørn Hansen
git-svn occasionally fails with no details as to what went wrong - this should help debug those situations.
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
---
perl/Git.pm | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 3f4080c..dca92c8 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -812,7 +812,7 @@ sub _cmd_exec {
$self->wc_subdir() and chdir($self->wc_subdir());
}
_execv_git_cmd(@args);
- die "exec failed: $!";
+ die qq[exec "@args" failed: $!];
}
# Execute the given Git command ($_[0]) with arguments ($_[1..])
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Johannes Schindelin @ 2007-11-06 10:53 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Junio C Hamano, git
In-Reply-To: <47303C2E.2070103@gmail.com>
Hi,
On Tue, 6 Nov 2007, Francesco Pretto wrote:
> Junio C Hamano ha scritto:
> >> ------------------------------------------------
> >> -$ git clone foo.com:/pub/repo.git/ my-project
> >> +$ git clone foo.com:/pub/scm/repo.git/ my-project
> >> $ cd my-project
> >> ------------------------------------------------
> >
> > This part seems an unnecessary change.
> >
>
> Ironically, that's the same configuration of git.kernel.org. And I think
> is better to put immediately the project in a appropriate directory than
> to move it later.
For most people, neither path is correct. So I really don't see your
point.
Ciao,
Dscho
^ permalink raw reply
* Re: git push problem - unpack unpacker exited with error code; ng refs/heads/rel2_branch n/a (unpacker error)
From: Johannes Schindelin @ 2007-11-06 10:51 UTC (permalink / raw)
To: Piet Delaney; +Cc: Pete/Piet Delaney, git, Piet Delaney
In-Reply-To: <47303826.1000506@bluelane.com>
Hi,
On Tue, 6 Nov 2007, Piet Delaney wrote:
> I'm getting an error when I try to push back a git repository
> that I just pulled and made a slight change to:
> -------------------------------------------------------------------------------------
> -bash-3.00$ git push
> [...]
> error: failed to push to 'git://cvs.bluelane.com/home/git/blux'
For security reasons, you cannot push to git://, by default. git:// does
not have any form of authentication or encryption.
You need to use the ssh protocol (probably something like
cvs.bluelane.com:/home/git/blux in your case).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement selectable group ownership in git-init
From: Wincent Colaiuta @ 2007-11-06 10:31 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Junio C Hamano, git
In-Reply-To: <472F98DE.2010406@gmail.com>
El 5/11/2007, a las 23:27, Francesco Pretto escribió:
> Wincent Colaiuta ha scritto:
>> I think this proposal adds unnecessary clutter to the codebase for
>> something that can easily be achieved (and *should*) using chown,
>> chgrp,
>> or "sudo -u" etc.
>
> While still not convinced about that "unnecessary", i had to admit
> the risk
> of breaking something with my addition was too high. What about a
> compromise?
> I have improved the documentation about shared repositories. A patch
> coming
> shortly.
Sounds like an excellent idea.
Cheers,
Wincent
^ permalink raw reply
* Re: [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories
From: Francesco Pretto @ 2007-11-06 10:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x5cmern.fsf@gitster.siamese.dyndns.org>
Junio C Hamano ha scritto:
>> ------------------------------------------------
>> -$ git clone foo.com:/pub/repo.git/ my-project
>> +$ git clone foo.com:/pub/scm/repo.git/ my-project
>> $ cd my-project
>> ------------------------------------------------
>
> This part seems an unnecessary change.
>
Ironically, that's the same configuration of git.kernel.org. And I think is better
to put immediately the project in a appropriate directory than to move it later.
> Don't assume the "admin privilege" part, as you do not have to.
>
Admin privilege SHALL be assumed, as this is a first time configuration, and the best
we can do is to assume it's done on a default *nix installation. Moreover, it's
what HEAD documentation is already doing when it suggests to give users ssh access.
Let's suppose the user "user1" create its own repository on a remote machine.
Now, he wants to selectively give write access on its repository to "user2".
There's 2 cases:
1) "user2" have a local/ssh account on the machine. In this case, "user1" want
to be sure only "user2" can write to the repository, so he can ask the admin
to put "user1" and "user2" in the same group "projectx" or ask him to enable
ACLs, still turned off in the majority of *nix systems.
2) "user2" haven't a local/ssh account. Here:
- a local/ssh account should be given to "user2", returning to 1)
- mod_dav module has to be enabled for public http dirs of "user1"
- git daemon has to be started and enabled to write on the repository.
The last 3 tasks all require admin privilege on default linux/bsd/macosx
installations. However, a little distinction can be made. I'll see.
>
> needs, and there is no reason members of projects A and B should
> be in the same group 'git'
I agree!
> while having members of project C in
> group 'hg' only because A and B happen to use git.
I agree!
> belong to 'src' group, or (2) make three groups, one for each
> project.
>
It's exactly the point of:
+It's recommended, but not necessary, to create a specific group of commiters
+for every project/repository. With root credentials launch:
+
+------------------------------------------------
+$ groupadd $group
+------------------------------------------------
What you have understood here?
> Also with the "create new --shared repository for the project in
> a group's directory that has mode 2755" approach, I do not think
> there is any need to muck with umask either.
>
umask requirement is referred to previous version of git. It's still referred as actual
in HEAD documentation. If it's ok for you, we could just cut away that reference.
Conclusion: i can try to amend my patch to be even more clearer. What i am saying
is that official documentation, commands manuals/syntaxes should be easy enough to the
first time user to set up git repositories without looking up the web for
"git tutorial"/"git installation"/"git umask 002", etc. (and consider that even an
expert sysadmin is a first time user, when he install and set up git the first time).
Or was better a "Documentation S**KS!" bug report?
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Andreas Ericsson @ 2007-11-06 9:47 UTC (permalink / raw)
To: Pierre Habouzit, Johannes Sixt, Johannes Schindelin
In-Reply-To: <20071106092648.GG4435@artemis.corp>
Pierre Habouzit wrote:
> On Tue, Nov 06, 2007 at 09:18:02AM +0000, Johannes Sixt wrote:
>> Pierre Habouzit schrieb:
>>> Btw, I'm starting to work slowly on the diff_opt_parse conversion to the
>>> macro we discussed, and the need for new option parsing callbacks
>>> arised, and I've created a:
>>> parse_opt_mask_{or,and,xor} commands that you declare this way:
>>> OPT_MASK_OR('a', "all", &mode, "...", MASK_ALL),
>>> OPT_MASK_OR('i', "interactive", &mode, "...", MASK_INTERACTIVE),
>>> ...
>>> And if you chose MASK_ALL/INTERACTIVE/.. to be single bits,
>>> if (!!all + !!interactive ... > 1)
>>> becomes[0]:
>>> if (mode & (mode - 1)) {
>>> }
>> This goes too far, IMHO. That's unnecessary cleverness/microoptimization
>> at the expense of readability.
>
> The reason why I did that is not to be able to do mode & (mode - 1).
With a macro along the lines of
#define IS_MULTI_FLAGGED(x) (x & (x - 1))
at least this particular construct becomes a lot more readable.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 9:37 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Johannes Schindelin, Steven Grimm, git
In-Reply-To: <20071106092942.GB3197@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]
On Tue, Nov 06, 2007 at 09:29:42AM +0000, Mike Hommey wrote:
> On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit <madcoder@debian.org> wrote:
> > On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> > > >
> > > >> Allowing people to revert or cherry pick partially by using paths
> > > >> limiter is a very good idea; the whole "it comes from a commit so we
> > > >> also commit" feels an utter nonsense, though.
> > > >
> > > > No.
> > > >
> > > > When "git revert <commit>" commits the result, "git revert <commit> --
> > > > <file>" should, too.
> > >
> > > I was not questioning about that part. "If 'git revert <some
> > > other form> foo' does not talk about commit, it should not
> > > commit" was what I was referring to.
> >
> > Well, I don't really know how closely you read #git, but I'd say that
> > "how do I undo my local changes in a git repository" is among the top 3
> > questions. There _IS_ an UI issue for that.
> >
> > If git revert <commitish> -- path1 path2 path3 is going to work at some
> > point, I see no harm in saying that git revert HEAD -- path1 path2 path3
> > work. We can also in that case spit an error message:
>
> It seems to me git revert HEAD -- path1 path2 path3 should revert the changes
> made in the commit pointed to by HEAD, not revert the changes in the working
> tree or the index...
Yes, sorry, the `HEAD` in my sentence was spurious.
--
·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: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Mike Hommey @ 2007-11-06 9:29 UTC (permalink / raw)
To: Pierre Habouzit, Junio C Hamano, Johannes Schindelin,
Steven Grimm, git
In-Reply-To: <20071106084925.GC4435@artemis.corp>
On Tue, Nov 06, 2007 at 09:49:25AM +0100, Pierre Habouzit <madcoder@debian.org> wrote:
> On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> > >
> > >> Allowing people to revert or cherry pick partially by using paths
> > >> limiter is a very good idea; the whole "it comes from a commit so we
> > >> also commit" feels an utter nonsense, though.
> > >
> > > No.
> > >
> > > When "git revert <commit>" commits the result, "git revert <commit> --
> > > <file>" should, too.
> >
> > I was not questioning about that part. "If 'git revert <some
> > other form> foo' does not talk about commit, it should not
> > commit" was what I was referring to.
>
> Well, I don't really know how closely you read #git, but I'd say that
> "how do I undo my local changes in a git repository" is among the top 3
> questions. There _IS_ an UI issue for that.
>
> If git revert <commitish> -- path1 path2 path3 is going to work at some
> point, I see no harm in saying that git revert HEAD -- path1 path2 path3
> work. We can also in that case spit an error message:
It seems to me git revert HEAD -- path1 path2 path3 should revert the changes
made in the commit pointed to by HEAD, not revert the changes in the working
tree or the index...
Mike
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Pierre Habouzit @ 2007-11-06 9:26 UTC (permalink / raw)
To: Johannes Sixt
Cc: Johannes Schindelin, Björn Steinbrink,
Kristian Høgsberg, Junio C Hamano, git
In-Reply-To: <4730314A.9010403@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]
On Tue, Nov 06, 2007 at 09:18:02AM +0000, Johannes Sixt wrote:
> Pierre Habouzit schrieb:
> >Btw, I'm starting to work slowly on the diff_opt_parse conversion to the
> >macro we discussed, and the need for new option parsing callbacks
> >arised, and I've created a:
> > parse_opt_mask_{or,and,xor} commands that you declare this way:
> > OPT_MASK_OR('a', "all", &mode, "...", MASK_ALL),
> > OPT_MASK_OR('i', "interactive", &mode, "...", MASK_INTERACTIVE),
> > ...
> >And if you chose MASK_ALL/INTERACTIVE/.. to be single bits,
> > if (!!all + !!interactive ... > 1)
> >becomes[0]:
> > if (mode & (mode - 1)) {
> > }
>
> This goes too far, IMHO. That's unnecessary cleverness/microoptimization
> at the expense of readability.
The reason why I did that is not to be able to do mode & (mode - 1).
Have a look at diff.c, imagine the insane amount of intermediate
variables we would need, and now understand why I introduced that :)
I'm not sure it's useful for git-commit, I was mentioning it just in case.
Note: the fact that an OPT_BOOLEAN when you repeat it increments the
value isn't always a good thing, and is the reason why you need
the (quite ugly) double bangs.
--
·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: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Johannes Sixt @ 2007-11-06 9:18 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, Björn Steinbrink,
Kristian Høgsberg, Junio C Hamano, git
In-Reply-To: <20071106091222.GE4435@artemis.corp>
Pierre Habouzit schrieb:
> Btw, I'm starting to work slowly on the diff_opt_parse conversion to the
> macro we discussed, and the need for new option parsing callbacks
> arised, and I've created a:
>
> parse_opt_mask_{or,and,xor} commands that you declare this way:
>
> OPT_MASK_OR('a', "all", &mode, "...", MASK_ALL),
> OPT_MASK_OR('i', "interactive", &mode, "...", MASK_INTERACTIVE),
> ...
>
> And if you chose MASK_ALL/INTERACTIVE/.. to be single bits,
>
> if (!!all + !!interactive ... > 1)
>
> becomes[0]:
>
> if (mode & (mode - 1)) {
>
> }
This goes too far, IMHO. That's unnecessary cleverness/microoptimization at
the expense of readability.
-- Hannes
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Pierre Habouzit @ 2007-11-06 9:12 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Björn Steinbrink, Kristian Høgsberg, Junio C Hamano,
git
In-Reply-To: <Pine.LNX.4.64.0711052317170.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
On Mon, Nov 05, 2007 at 11:18:36PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 5 Nov 2007, Bj?rn Steinbrink wrote:
>
> > On 2007.11.05 13:57:53 -0500, Kristian H?gsberg wrote:
> >
> > > The shell script just has
> > >
> > > case "$all,$interactive,$also,$#" in
> > > *t,*t,*)
> > > die "Cannot use -a, --interactive or -i at the same time." ;;
> > >
> > > which doesn't seem to care about the value of $also. As far as I
> > > understand git commit, it doesn't make sense to pass any of -a, -i, -o
> > > or --interactive at the same time so I guess I could join the checks
> >
> > Note that there are only two commas. The asterisks catch everything and
> > $# won't be "t", so that catches anything with at least two t's.
>
> So shouldn't it be
>
> if (!!all + !!interactive + !!also > 1)
Btw, I'm starting to work slowly on the diff_opt_parse conversion to the
macro we discussed, and the need for new option parsing callbacks
arised, and I've created a:
parse_opt_mask_{or,and,xor} commands that you declare this way:
OPT_MASK_OR('a', "all", &mode, "...", MASK_ALL),
OPT_MASK_OR('i', "interactive", &mode, "...", MASK_INTERACTIVE),
...
And if you chose MASK_ALL/INTERACTIVE/.. to be single bits,
if (!!all + !!interactive ... > 1)
becomes[0]:
if (mode & (mode - 1)) {
}
I've not read your patch thoroughly, but if you feel such a thing would
help you, I could send a preliminar set of patches to enable this
feature for people that may need it. Though you can look at my WIP on my
git public repository[1].
For those who care, this need arised because parse_diff_opts have a
_lot_ of single bit options, and that expansing it on many many full
blown integers looked like a regression, so I took the option to have a
`flags` member with explicit masks, and those masks will be used from
the parse-option callbacks[2]
[0] for those who don't already know it, (i & (i - 1)) == 0
iff i is 0 or a power of 2.
[1] the patch[3]:
http://git.madism.org/?p=git.git;a=commitdiff;h=9d75b0a00915fa81657934f36318c1c0f5bac96b
example of use:
http://git.madism.org/?p=git.git;a=commitdiff;h=74aacc487579d0cbd638adf883e743caeaee0f76
http://git.madism.org/?p=git.git;a=commitdiff;h=af15793dde94119faa1577c9eec7e839ae628011
[2] http://git.madism.org/?p=git.git;a=commitdiff;h=86032204f1bdf5da2fee555ec917709b3e6f662c#patch10
[3] oh boy gitweb urls are really way too long :/
--
·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 pull opinion
From: Andreas Ericsson @ 2007-11-06 8:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Junio C Hamano, Aghiles, git
In-Reply-To: <Pine.LNX.4.64.0711060115130.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Andreas Ericsson wrote:
>
>> Bill Lear wrote:
>>> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
>>>> Aghiles <aghilesk@gmail.com> writes:
>>>>
>>>>> Is there an "easier" way to pull into a dirty directory ? I am
>>>>> asking this to make sure I understand the problem and not
>>>>> because I find it annoying to type those 4 commands to perform
>>>>> a pull (although some of my colleagues do find that annoying :).
>>>> You need to switch your mindset from centralized SVN workflow.
>>>>
>>>> The beauty of distributedness is that it redefines the meaning
>>>> of "to commit". In distributed systems, the act of committing
>>>> is purely checkpointing and it is not associated with publishing
>>>> the result to others as centralized systems force you to.
>>>>
>>>> Stop thinking like "I need to integrate the changes from
>>>> upstream into my WIP to keep up to date." You first finish what
>>>> you are currently doing, at least to the point that it is
>>>> stable, make a commit to mark that state, and then start
>>>> thinking about what other people did. You may most likely do a
>>>> "git fetch" followed by "git rebase" to update your WIP on top
>>>> of the updated work by others.
>>>>
>>>> Once you get used to that, you would not have "a dirty
>>>> directory" problem.
>>> I respectfully beg to differ. I think it is entirely reasonable, and
>>> not a sign of "centralized" mindset, to want to pull changes others
>>> have made into your dirty repository with a single command.
>>>
>> I find it much more convenient to just fetch them. I'd rather see
>> git-pull being given a --rebase option (which would ultimately mean
>> teaching git-merge about it) to rebase already committed changes on
>> top of the newly fetched tracking branch. It's being worked on, but
>> rather slowly.
>
> git-pull learning about --rebase does not mean teaching git-merge about
> it. See my patch, which you (and others) failed to enthusiastically
> embrace, which is the sole reason it is stalled.
>
I must have missed it. Found the thread now though. Gonna try the patch in
production for a while and see how it pans out.
I'm curious about this hunk though. It seems unaffiliated with the --rebase
option as such, but was still in the patch. Would you care to clarify?
@@ -86,7 +95,6 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
- curr_branch=$(git symbolic-ref -q HEAD)
case $? in
0) ;;
1) echo >&2 "You are not currently on a branch; you must explicitly"
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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