* Re: [PATCH v3 2/3] fast-import: add option command
From: Shawn O. Pearce @ 2009-08-14 17:39 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Johannes Schindelin, Git List
In-Reply-To: <fabb9a1e0908140937h32a2eac7ka88f76aa417fd631@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Aug 14, 2009 at 08:37, Shawn O. Pearce<spearce@spearce.org> wrote:
> > Sverre Rabbelier <srabbelier@gmail.com> wrote:
> >> +`option`
> >> +~~~~~~~~
> >> +Processes the specified option so that git fast-import behaves in a
> >> +way that suits the frontend's needs.
> >> +Note that options specified by the frontend are overridden by any
> >> +options the user may specify to git fast-import itself.
> >
> > Wha? ?This disagrees with the code.
>
> It does? It's saying that the user my override what the frontend
> specifies, which is what the current version does.
Sorry, lack of caffeine. Rereading the docs makes sense.
> >> + ? ? if (!seen_non_option_command)
> >> + ? ? ? ? ? ? parse_argv();
> >
> > This is too late.
>
> No it's not. Earlier in the patch, at the other
> 'seen_non_option_command', we call parse_argv() as well (which happens
> when a non-option command is issued). This statement is here to deal
> with options that affect an empty stream, such as 'git format-patch
> --import-marks=marks.old --export-marks=marks.new < /dev/null &&
> test_cmp marks.old marks.new'.
Oy, I missed that call. I looked for it but gave up too soon I guess.
> > So yea, I really do think its a good idea for command line options
> > to override stream options, despite what Dscho may think. ?:-)
>
> Which is what the current version does, yes?
Yes. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH v3 2/3] fast-import: add option command
From: Sverre Rabbelier @ 2009-08-14 17:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Johannes Schindelin, Git List
In-Reply-To: <20090814173929.GU1033@spearce.org>
Heya,
On Fri, Aug 14, 2009 at 10:39, Shawn O. Pearce<spearce@spearce.org> wrote:
> Sorry, lack of caffeine. Rereading the docs makes sense.
Perfectly acceptable, I totally though the 'break' in a 'switch'
statement would break out of the outer for loop the other day.
>> > So yea, I really do think its a good idea for command line options
>> > to override stream options, despite what Dscho may think. ?:-)
>>
>> Which is what the current version does, yes?
>
> Yes. :-)
Ok, I think perhaps we can wait 'nother day to see if anyone notices
anything (possibly after more caffeine) and then ask Junio to apply?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git-config: Parse config files leniently
From: Junio C Hamano @ 2009-08-14 19:52 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, David Reitter, Jakub Narebski
In-Reply-To: <a812f567b4541ce55e9c60037a047488a0893c36.1250262273.git.git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Currently, git config dies as soon as there is a parsing error. This is
> especially unfortunate in case a user tries to correct config mistakes
> using git config -e.
>
> Instead, issue a warning only and treat the rest of the line as a
> comment (ignore it). This benefits not only git config -e users.
... a broken sentence in the middle? I would have expected the "not only"
followed by "but also"; the question is "but also what?"
Hopefully the benefit is not that it now allows all the other commands to
cause unspecified types of damage to the repository by following iffy
settings obtained from a broken configuration file.
> Reported-by: David Reitter <david.reitter@gmail.com>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> Test had to be adjusted as well.
The change to the test demonstrates the issue rather well. The check()
shell function does not check the exit value from "git config --get", but
in a real script that cares to check and stop on error, this change will
now let the script go on, leaving the breakage unnoticed. I suspect
command implemented in C, that call git_config(), will also have the same
issue, and I cannot convince myself this is a good change in general,
outside the scope of helping "git config -e".
But I may be being overly cautious.
By the way, why did you have to change s/echo/printf/? Can't you give two
lines in a single argument without "\n" escape?
> diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
> index 080117c..be850c5 100755
> --- a/t/t1303-wacky-config.sh
> +++ b/t/t1303-wacky-config.sh
> @@ -9,7 +9,7 @@ setup() {
> }
>
> check() {
> - echo "$2" >expected
> + printf "$2\n" >expected
> git config --get "$1" >actual 2>&1
> test_cmp actual expected
> }
> @@ -44,7 +44,7 @@ LONG_VALUE=$(printf "x%01021dx a" 7)
> test_expect_success 'do not crash on special long config line' '
> setup &&
> git config section.key "$LONG_VALUE" &&
> - check section.key "fatal: bad config file line 2 in .git/config"
> + check section.key "warning: bad config file line 2 in .git/config\nwarning: bad config file line 2 in .git/config"
> '
>
> test_done
^ permalink raw reply
* Re: [PATCH] git submodule summary: add --files option
From: Junio C Hamano @ 2009-08-14 19:52 UTC (permalink / raw)
To: hjemli; +Cc: git, Jens Lehmann
In-Reply-To: <4A846A62.7010306@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> git submodule summary is providing similar functionality for submodules as
> git diff-index does for a git project (including the meaning of --cached).
> But the analogon to git diff-files is missing, so add a --files option to
> summarize the differences between the index of the super project and the
> last commit checked out in the working tree of the submodule.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Makes sense to me. Comments?
^ permalink raw reply
* Re: [PATCH] git stash: Give friendlier errors when there is nothing to apply
From: Junio C Hamano @ 2009-08-14 19:52 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Ori Avtalion
In-Reply-To: <4a81787d.0e0f660a.5238.4c8b@mx.google.com>
Ori Avtalion <ori@avtalion.name> writes:
> The change makes sure a stash (given or default) exists before
> checking if the working tree is dirty.
>
> If the default stash is requested, the old message was scary and
> included a 'fatal' error from rev-parse:
> fatal: Needed a single revision
> : no valid stashed state found
>
> It is replaced with a friendlier 'Nothing to apply' error, similar to
> 'git stash branch'.
>
> If a specific stash is specified, the 'Needed a single revision' errors
> from rev-parse are suppressed.
>
> Signed-off-by: Ori Avtalion <ori@avtalion.name>
> Acked-by: Thomas Rast <trast@student.ethz.ch>
I do not see anything that might break existing usage of the command.
Comments?
A tangent; we might want an analogue to "shortlog -s -n" but based on
"blame".
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Junio C Hamano @ 2009-08-14 19:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: Luke Dashjr, git
In-Reply-To: <200908132306.37947.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano wrote:
>>
>> Chould you refresh my memory a bit?
>>
>> In what circumstance is "rm --ignore-unmatch" useful to begin with?
>
> Not sure about add --ignore-unmatch myself, but there's even an
> example of rm --ignore-unmatch in man git-filter-branch, along the
> lines of
>
> git filter-branch --index-filter '
> rm --ignore-unmach some_file_that_shouldnt_be_in_history
> ' -- --all
Ah, that makes sense. I am not sure about "add --ignore-unmatch" myself
either, and an example similar to the above filter-branch would not apply
very easily (i.e. "add a file that should have been in history" would not
need --ignore-unmatch).
^ permalink raw reply
* Re: trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 20:10 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: git
In-Reply-To: <606CC410B038E34CB97646A32D0EC0BF0181FAB4@venusbis.synchrotron-soleil.fr>
2009/8/14 PICCA Frédéric-Emmanuel
<frederic-emmanuel.picca@synchrotron-soleil.fr>:
> mordor% git am /home/picca/Projets/patches/0001-Add-the-POGO-TO-DELETE-comment-to-ComputedAnglesClea.patch
> Applying: 'Add the POGO TO DELETE comment to ComputedAnglesClear command'
> /tmp/diffractometer/.git/rebase-apply/patch:13: trailing whitespace.
>
> /tmp/diffractometer/.git/rebase-apply/patch:14: trailing whitespace.
> /* POGO TO DELETE */
> error: patch failed: src/Diffractometer/Diffractometer.cpp:2023
> error: src/Diffractometer/Diffractometer.cpp: patch does not apply
This patch has DOS line endings (like CR, followed by LF).
You can either use dos2unix (or your editor of choice), or update your git
to current master branch, where "git am" handles such patches transparently.
^ permalink raw reply
* RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 20:21 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0908141310x7e4acf4fgf4ea71cf53de6eea@mail.gmail.com>
> This patch has DOS line endings (like CR, followed by LF).
> You can either use dos2unix (or your editor of choice), or update your git
> to current master branch, where "git am" handles such patches transparently.
I am using git 1.6.3.3 debian unstable is it ok ?
In fact we saw that this problem was due to our webmail
the patch was attached to a mail and using the webmail interface a save to disk transform the CR -> CR LF
we tested it with gmail and the microsoft webmail
now the problem is that a patch with CR+ LF do not have the same signature that a patch
with only CR.
how can I do the difference between a patch with normal CR+LF (the autor use this format)
and a patch without CR+LF due to the webmail ?
See you
Frederic
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Jakub Narebski @ 2009-08-14 20:23 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <fcaeb9bf0908130538x396b1208s43d312107e3e198c@mail.gmail.com>
Dnia czwartek 13. sierpnia 2009 14:38, Nguyen Thai Ngoc Duy napisał:
> On 8/13/09, Jakub Narebski <jnareb@gmail.com> wrote:
>> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>>> 2009/8/12 Junio C Hamano <gitster@pobox.com>:
>>
>>>> It could also require core.sparseworktree configuration set to true if we
>>>> are really paranoid, but without the actual sparse specification file
>>>> flipping that configuration to true would not be useful anyway, so in
>>>> practice, giving --sparse-work-tree option to these Porcelain commands
>>>> would be no-op, but --no-sparse-work-tree option would be useful to
>>>> ignore $GIT_DIR/info/sparse and populate the work tree fully.
>>>
>>> Only part "ignore $GIT_DIR/info/sparse" is correct.
>>> "--no-sparse-work-tree" would not clear CE_VALID from all entries in
>>> index (which is good, if you are using CE_VALID for another purpose).
>>>
>>> To quit sparse checkout, you must create an empty
>>> $GIT_DIR/info/sparse, then do "git checkout" or "git read-tree -m -u
>>> HEAD" so that the tree is full populated, then you can remove
>>> $GIT_DIR/info/sparse. Quite unintuitive..
>>
>>
>> Hmmm... this looks like either argument for introducing --full option
>> to git-checkout (ignore CE_VALID bit, checkout everything, and clean
>> CE_VALID (?))...
>>
>> ...or for going with _separate_ bit for partial checkout, like in the
>> very first version of this series, which otherwise functions like
>> CE_VALID, or is just used to mark that CE_VALID was set using sparse.
>
> In my opinion, making an empty .git/info/sparse to fully populate
> worktree is not too bad. I wanted to have plumbing-level support in
> git so that you could try sparse checkout on your projects (possibly
> with a few additional scripts to make your life easier). Then good
> Porcelain UI may emerge later (or in worst case, people would roll
> their own sparse checkout).
Deciding whether sparse checkout should use CE_VALID only, or should it
(as it was in the very first version of series) use additional flag,
either CE_NO_CHECKOUT, or CE_VALID_IS_USED_HERE_FOR_SPARSE_CHECKOUT ;-)
is a design decision about *plumbing-level* support.
Note that shallow clone, while using the same mechanism as grafts file,
nevertheless use separate file; so perhaps sparse checkout while using
the same mechanism as --assume-unchanged should use additional flag.
BTW. you might want to use GIT_SPARSE_FILE, similar to GIT_INDEX_FILE;
see the fact that plumbing doesn't have .gitignore not .git/info/excludes
hardcoded... well, except for --standard-excludes. This way full
checkout would be as simple as using
$ GIT_SPARSE_FILE= git checkout -- .
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH 0/2] add a --delete option to git push
From: Jakub Narebski @ 2009-08-14 20:25 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0908140953w2d3f571cv3e7415817c2758a7@mail.gmail.com>
Dnia piątek 14. sierpnia 2009 18:53, Sverre Rabbelier napisał:
> 2009/8/14 Jakub Narebski <jnareb@gmail.com>:
>> On Fri, 14 August 2009, Sverre Rabbelier wrote:
>>>
>>> This is in reply to a brief conversation I had with jnareb on #git
>>> about the blogpost "5 things git could learn from hg", or something
>>> like that (can't find it right now).
>>
>> Thanks.
>
> What do you think would be the best solution? There seem to be a lot
> of opinions on how to proceed.
I think we can begin with simple and strict: "--delete=<branch>"
is long version of equivalent ":<branch>" (like long option equivalent
to short one).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: RE : trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 20:31 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: git
On Fri, Aug 14, 2009 at 22:21, PICCA
Frédéric-Emmanuel<frederic-emmanuel.picca@synchrotron-soleil.fr>
wrote:
>> This patch has DOS line endings (like CR, followed by LF).
>
>> You can either use dos2unix (or your editor of choice), or update your git
>> to current master branch, where "git am" handles such patches transparently.
>
> I am using git 1.6.3.3 debian unstable is it ok ?
No. I just checked - it is not even in master yet. You can merge
the commits at c2ca1d79dbd54b06. That's what I am using. These
are merged in Junio's next already, so you'll see them in master
someday. Meanwhile I can have it like this:
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git merge c2ca1d79dbd54b06
$ make && make test && make doc
$ make install install-doc
This will install the freshly compiled git in your home (~/bin,
~/share, ~/libexec, ...)
I would recommend to remove the debian's git first, BTW.
> how can I do the difference between a patch with normal CR+LF (the autor use this format)
> and a patch without CR+LF due to the webmail ?
Just replace the trailing CR+LF with just LF. The program named
"dos2unix" does that.
^ permalink raw reply
* Re: RE : trailling whitespace with git am ?
From: Junio C Hamano @ 2009-08-14 20:31 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: Alex Riesen, git
In-Reply-To: <606CC410B038E34CB97646A32D0EC0BF0181FABD@venusbis.synchrotron-soleil.fr>
PICCA Frédéric-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr>
writes:
> how can I do the difference between a patch with normal CR+LF (the autor use this format)
> and a patch without CR+LF due to the webmail ?
That is a question to your webmail provider but I think you generally
can't. Use dos2unix as Alex suggested and you should be fine.
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Luke-Jr @ 2009-08-14 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Luke Dashjr, git
In-Reply-To: <7vws56i35q.fsf@alter.siamese.dyndns.org>
On Friday 14 August 2009 02:52:33 pm Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> > Junio C Hamano wrote:
> >> Chould you refresh my memory a bit?
> >>
> >> In what circumstance is "rm --ignore-unmatch" useful to begin with?
> >
> > Not sure about add --ignore-unmatch myself, but there's even an
> > example of rm --ignore-unmatch in man git-filter-branch, along the
> > lines of
> >
> > git filter-branch --index-filter '
> > rm --ignore-unmach some_file_that_shouldnt_be_in_history
> > ' -- --all
>
> Ah, that makes sense. I am not sure about "add --ignore-unmatch" myself
> either, and an example similar to the above filter-branch would not apply
> very easily (i.e. "add a file that should have been in history" would not
> need --ignore-unmatch).
The purpose of "add --ignore-unmatch" is to ignore race conditions where one
of the files to be added has been deleted after git is executed, but before
git scans it.
^ permalink raw reply
* RE : RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vab22i1dl.fsf@alter.siamese.dyndns.org>
> how can I do the difference between a patch with normal CR+LF (the autor use this format)
> and a patch without CR+LF due to the webmail ?
> That is a question to your webmail provider but I think you generally
> can't. Use dos2unix as Alex suggested and you should be fine.
git am --whitespace=fix was sufficient to apply the patch
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Luke-Jr @ 2009-08-14 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Luke Dashjr, git
In-Reply-To: <200908141539.18087.luke@dashjr.org>
Specific use-case of "git add --ignore-unmatched":
http://gitorious.org/gitbackup
Without this functionality, daily race conditions will break the
synchronisation.
^ permalink raw reply
* Re: RE : RE : trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 20:48 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: Junio C Hamano, git
On Fri, Aug 14, 2009 at 22:46, PICCA
Frédéric-Emmanuel<frederic-emmanuel.picca@synchrotron-soleil.fr>
wrote:
>> how can I do the difference between a patch with normal CR+LF (the autor use this format)
>> and a patch without CR+LF due to the webmail ?
>
>> That is a question to your webmail provider but I think you generally
>> can't. Use dos2unix as Alex suggested and you should be fine.
>
> git am --whitespace=fix was sufficient to apply the patch
>
Depending on your situation it can be an overkill: it'll remove _all_ trailing
white space. Not just \r (CR).
^ permalink raw reply
* RE : RE : RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 20:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0908141348icee65d6kf4188cbd68405c0c@mail.gmail.com>
> > git am --whitespace=fix was sufficient to apply the patch
> Depending on your situation it can be an overkill: it'll remove _all_ trailing
> white space. Not just \r (CR).
so /s /t and /r are the same things for git ?
^ permalink raw reply
* [PATCH v5 0/6] Re: {checkout,reset,stash} --patch
From: Nicolas Sebrecht @ 2009-08-14 20:57 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, git, Jeff King, Sverre Rabbelier,
Nanako Shiraishi, Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <cover.1250164190.git.trast@student.ethz.ch>
The 13/08/09, Thomas Rast wrote:
> Junio C Hamano wrote:
> > * tr/reset-checkout-patch (Tue Jul 28 23:20:12 2009 +0200) 8 commits
> [...]
> > Progress?
>
> Slow, as always. There are three groups of changes:
<...>
> Thomas Rast (7):
> git-apply--interactive: Refactor patch mode code
> Add a small patch-mode testing library
> builtin-add: refactor the meat of interactive_add()
> Implement 'git reset --patch'
> Implement 'git checkout --patch'
> Implement 'git stash save --patch'
> DWIM 'git stash save -p' for 'git stash -p'
Tested-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
--
Nicolas Sebrecht
^ permalink raw reply
* Re: rebase-with-history -- a technique for rebasing without trashing your repo history
From: Michael Haggerty @ 2009-08-14 21:21 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Git Mailing List
In-Reply-To: <20090813233027.GA19833@atjola.homenet>
Björn Steinbrink wrote:
> On 2009.08.14 00:39:48 +0200, Michael Haggerty wrote:
>> Björn Steinbrink wrote:
>>> On 2009.08.13 14:46:07 +0200, Michael Haggerty wrote:
>>> And even for just continously forward porting a series of commits, a
>>> common case might be that upstream applied some patches, but not all.
>>> Can you deal with that?
[A discussion of various unsatisfactory approaches omitted...]
> But that's obviously total crap.
So I think we agree that it is not possible to retain history for a case
like this (which is essentially a general cherry-pick).
> [...]
> Doing a plain "git rebase subsystem topic" would of course also try to
> rebase the "o" commits, so that problematic. Instead, you do:
>
> git rebase --onto subsystem O topic
>
> That turns O..topic (the * commits) into patches, and applies them on
> top of O'. So the "o" commits aren't to be rebased.
>
> And that's exactly what your rebase-with-history would do as well. Just
> that O is naturally a common ancestor of subsystem and topic, and so
> just using "git rebase-w-h subsystem topic" would be enough. Conflicts
> etc. should be 100% the same.
>
> If you know that your upstream is going to rebase/rewrite history, you
> can tag (or otherwise mark) the current branching point of your branch,
> so you can easily specify it for the --onto rebase. IOW: This is
> primarily a social problem (tell your downstream that you rebase this or
> that branch), but having built-in support to store the branching point
> for rebasing _might_ be worth a thought.
Recording branch points manually, coordinating merges via email -- OMG
you are giving me flashbacks of CVS ;-)
*Of course* you can get around all of these problems if you put the
burden of bookkeeping on the user. The whole point of
rebase-with-history is to have the VCS handle it automatically!
>> and merging in a topic branch makes it more difficult to create an
>> easily-reviewable patch series. rebase-with-history has neither of
>> these problems.
>
> Sure, merging is a no-go if you submit patches by email (or other,
> similar means). But you compared that to an "enhanced" rebase approach,
> instead of comparing your rebase approach to the currently available
> one.
In [1] I compared rebase-with-history with both of the
currently-available options (rebase and merge). Rebase and merge can
each deal with some of the issues that come up, but each one falls flat
on others. I believe that rebase-with-history has the advantages of both.
The example in [2] was taken straight from the git-rebase man page [3];
I did not want to claim that current practice would use merging in this
situation, but rather just to show that rebase-with-history removes the
pain from this well-known example.
I think we are mostly in agreement. Rebase-with-history is obviously
not an earth-shattering revolution in DVCS technology, but my hope is
that it could unobtrusively assist with a few minor pain points.
Michael
[1]
http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html
[2]
http://softwareswirl.blogspot.com/2009/08/upstream-rebase-just-works-if-history.html
[3] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
^ permalink raw reply
* Re: [PATCH] git stash: Give friendlier errors when there is nothing to apply
From: Nanako Shiraishi @ 2009-08-14 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ori Avtalion
In-Reply-To: <7v3a7ujhqb.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Ori Avtalion <ori@avtalion.name> writes:
>
>> The change makes sure a stash (given or default) exists before
>> checking if the working tree is dirty.
>>
>> If the default stash is requested, the old message was scary and
>> included a 'fatal' error from rev-parse:
>> fatal: Needed a single revision
>> : no valid stashed state found
>>
>> It is replaced with a friendlier 'Nothing to apply' error, similar to
>> 'git stash branch'.
>>
>> If a specific stash is specified, the 'Needed a single revision' errors
>> from rev-parse are suppressed.
>>
>> Signed-off-by: Ori Avtalion <ori@avtalion.name>
>> Acked-by: Thomas Rast <trast@student.ethz.ch>
>
> I do not see anything that might break existing usage of the command.
> Comments?
The patch looks good to me. I think it was my fault but you can avoid
adding two extra --quiet by inspecting i_tree (in other words, "$s^2:")
before w_tree and b_tree. Because a commit that is a stash exactly has
two parents, it may be good to also make sure 'git rev-parse "$s^3"'
fails.
s=$(git rev-parse --verify --default $ref_stash "$@") &&
! git rev-parse --quiet --verify "$s^3" >/dev/null &&
i_tree=$(git rev-parse --quiet --verify "$s^2:") &&
b_tree=$(git rev-parse --verify "$s^1:") &&
w_tree=$(git rev-parse --verify "$s:") ||
die "$*: no valid stashed state found"
> A tangent; we might want an analogue to "shortlog -s -n" but based on
> "blame".
I'm sorry, I don't understand what you mean.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Nanako Shiraishi @ 2009-08-14 21:39 UTC (permalink / raw)
To: Luke-Jr; +Cc: Junio C Hamano, Thomas Rast, Luke Dashjr, git
In-Reply-To: <200908141539.18087.luke@dashjr.org>
Quoting "Luke-Jr" <luke@dashjr.org>
> On Friday 14 August 2009 02:52:33 pm Junio C Hamano wrote:
>> Thomas Rast <trast@student.ethz.ch> writes:
>> > Junio C Hamano wrote:
>> >> Chould you refresh my memory a bit?
>> >>
>> >> In what circumstance is "rm --ignore-unmatch" useful to begin with?
>> >
>> > Not sure about add --ignore-unmatch myself, but there's even an
>> > example of rm --ignore-unmatch in man git-filter-branch, along the
>> > lines of
>> >
>> > git filter-branch --index-filter '
>> > rm --ignore-unmach some_file_that_shouldnt_be_in_history
>> > ' -- --all
>>
>> Ah, that makes sense. I am not sure about "add --ignore-unmatch" myself
>> either, and an example similar to the above filter-branch would not apply
>> very easily (i.e. "add a file that should have been in history" would not
>> need --ignore-unmatch).
>
> The purpose of "add --ignore-unmatch" is to ignore race conditions where one
> of the files to be added has been deleted after git is executed, but before
> git scans it.
First of all, it should have been mentioned as part of your proposed commit log message.
Second of all, if a race condition makes an "add" fail, isn't it a good thing? If your "add" ignored such a failure, you'd be recording an inconsistent or incomplete state.
IMHO, fixing your racy script is a much cleaner solution to your problem than forcing "git add" to ignore errors.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: rebase-with-history -- a technique for rebasing without trashing your repo history
From: Nanako Shiraishi @ 2009-08-14 21:40 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Bjrn Steinbrink, Git Mailing List
In-Reply-To: <4A85D53D.9050805@alum.mit.edu>
Quoting Michael Haggerty <mhagger@alum.mit.edu>
> In [1] I compared rebase-with-history with both of the
> currently-available options (rebase and merge). Rebase and merge can
> each deal with some of the issues that come up, but each one falls flat
> on others. I believe that rebase-with-history has the advantages of both.
> .... Rebase-with-history is obviously
> not an earth-shattering revolution in DVCS technology, but my hope is
> that it could unobtrusively assist with a few minor pain points.
The saddest part is that your [1] works only in a case a user can easily handle manually, and doesn't help cases more complex than the most trivial ones, such as reordering and squashing commits, where the user may benefit if an automated support from VCS were available.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 21:43 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: Junio C Hamano, git
On Fri, Aug 14, 2009 at 22:50, PICCA
Frédéric-Emmanuel<frederic-emmanuel.picca@synchrotron-soleil.fr>
wrote:
>> > git am --whitespace=fix was sufficient to apply the patch
>
>> Depending on your situation it can be an overkill: it'll remove _all_ trailing
>> white space. Not just \r (CR).
>
> so /s /t and /r are the same things for git ?
>
almost. For git-apply's whitespace fixing code. Why?
^ permalink raw reply
* RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 21:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0908141443vc54c009o9ec39b3f617311dd@mail.gmail.com>
> > so /s /t and /r are the same things for git ?
> almost. For git-apply's whitespace fixing code. Why?
Because for the user the message trailling whitespace was not clear
In fact the problem was a dos/unix format not a trailling space.
but whitespace=fix solve this problem. I was surprise first because I was looking for
remaining space at the end of lines of the patch not this CR+LF things.
Maybe git apply should warn the user a different way if their is that sort of dos/unix imcompatibilities.
thanks
Frederic
^ permalink raw reply
* Re: RE : trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 22:16 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: Junio C Hamano, git
On Fri, Aug 14, 2009 at 23:50, PICCA
Frédéric-Emmanuel<frederic-emmanuel.picca@synchrotron-soleil.fr>
wrote:
> Maybe git apply should warn the user a different way if their is that sort of
> dos/unix imcompatibilities.
As it all is history (in the new code) already, there is nothing to talk about.
Git-am in "next" branch just accepts such a patch without a warning.
^ 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