* Re: Honoring a checked out gitattributes file
From: Jeff King @ 2009-01-28 17:55 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <498078F1.20807@trolltech.com>
On Wed, Jan 28, 2009 at 04:25:37PM +0100, Kristian Amlie wrote:
> However, if the .gitattributes file is also checked in to the branch, it
> will not always be honored. I browsed the code a bit, and it seems to
> happen whenever there is an existing .gitattributes file, but the
> checkout adds new files to it. These new files will not get the correct
> line endings (although I'm not sure if it happens *every* time, it could
> depend on the order they are checked out).
This is a known limitation of gitattributes. There has been some
discussion in the past on how it should work, but I don't recall the
specifics; try searching the list archive. I think it is really just
waiting for somebody to step up and write some patches.
As a workaround, you might be able to do something like:
branch=master
git show $branch:.gitattributes >.git/info/attributes
git checkout $branch
which is very hacky, but might work depending on your setup. Notably it
will overwrite any actual use you were making of .git/info/attributes,
and it will not respect any .gitattributes files in subdirectories.
-Peff
^ permalink raw reply
* Re: [PATCH v3 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jeff King @ 2009-01-28 17:51 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Jay Soffian, git, gitster, sverre
In-Reply-To: <780A42F8-E27C-404A-945C-38C16378EF57@ai.rug.nl>
On Wed, Jan 28, 2009 at 04:18:30PM +0000, Pieter de Bie wrote:
> FWIW, I sometimes like to run 'git am', paste in a patch and hit ctrl-d.
I have to admit, I usually am opposed to this sort of terminal DWIMmery
for exactly that reason. But I don't personally ever cut and paste into
git-am, so I was trying not to raise a fuss. ;)
-Peff
^ permalink raw reply
* Re: Honoring a checked out gitattributes file
From: Kristian Amlie @ 2009-01-28 17:25 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49808B53.6040907@drmicha.warpmail.net>
Michael J Gruber wrote:
> I think there's a general time ordering problem. Say you do the
> following commits:
>
> A: add a.txt
> B: add a .gitattributes file covering *.txt (say with crlf or any filter)
> C: add c.txt
>
> Now, with an empty dir, you do either
>
> 1) checkout A, B, C sequentially
> 2) checkout C
>
> The contents of the checkout will be different in cases 1) and 2):
> 1) a.txt is checked out out as is, c.txt according to the attributes
> 2) with current git: probably like 1), with your suggestion: both a.txt
> and c.txt filtered according to the attributes.
>
> If you add a file and .gitattributes covering it in the same commit
> there is an ordering ambiguity which can be solved (patched away)
> easily, but I think the difference between 1) and 2) is still
> problematic, and would need to be dealt with.
I agree.
>
> The main problem seems to be that changing a file like gitattributes can
> potentially change (by changing filters) the contents which should be
> stored for a different file even if the checkout of that file doesn't
> change.
Yes, that is a problem. Ideally, the crlf attribute would be tied to the
file entry itself rather than a separate file (so changing the attribute
would mean a change to the file), but I guess we are stuck with what we
have.
I still think that case 2) is the most common, and fixing it has the
appealing property that if the repository line endings are broken for
some reason (because of case 1 or something else), then recloning or
checking out from scratch is guaranteed to bring the working tree into
the "correct" state.
Since fixing both cases is a pretty big task and fixing only case 2 is
small, I propose that we go ahead with that.
--
Kristian Amlie
^ permalink raw reply
* Vim's gitconfig filetype (and folding)
From: Ted Pavlic @ 2009-01-28 16:56 UTC (permalink / raw)
To: git, vim_use
[-- Attachment #1: Type: text/plain, Size: 918 bytes --]
I don't know who is responsible for maintaining the git-related files
distributed with Vim, but it would be nice if folding was enable for the
gitconfig filetype.
I've attached a sample set of folding rules that works well for me...
Right now I have the attached file in ~/.vim/ftplugin/gitconfig.vim.
I'll paste those rules here (but beware of word wrap):
:set
foldexpr=getline(v:lnum)=~'^[;#]\\s*\\(ex\\\|vi\\\|vim\\):'?\">1\":((getline(v:lnum)=~\"^#\\\\=[\")?\">1\":\"1\")
:set fdm=expr
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
[-- Attachment #2: gitconfig.vim --]
[-- Type: text/plain, Size: 133 bytes --]
:set foldexpr=getline(v:lnum)=~'^[;#]\\s*\\(ex\\\|vi\\\|vim\\):'?\">1\":((getline(v:lnum)=~\"^#\\\\=[\")?\">1\":\"1\")
:set fdm=expr
^ permalink raw reply
* [PATCH] git-p4: avoid syncing duplicate changes
From: Pete Wyckoff @ 2009-01-28 16:45 UTC (permalink / raw)
To: git
When a particular changeset affects multiple depot paths, it
will appear multiple times in the output of "p4 changes".
Filter out the duplicates to avoid the extra empty commits that
this would otherwise create.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index a85a7b2..63c8eca 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -444,8 +444,9 @@ def p4ChangesForPaths(depotPaths, changeRange):
changes = []
for line in output:
- changeNum = line.split(" ")[1]
- changes.append(int(changeNum))
+ changeNum = int(line.split(" ")[1])
+ if changeNum not in changes:
+ changes.append(changeNum)
changes.sort()
return changes
--
1.6.0.6
^ permalink raw reply related
* Re: Honoring a checked out gitattributes file
From: Michael J Gruber @ 2009-01-28 16:44 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <498078F1.20807@trolltech.com>
Kristian Amlie venit, vidit, dixit 28.01.2009 16:25:
> Hi!
>
> We currently use msysGit in our company test farm to checkout the latest
> development branch and do autotests. However, we have one problem:
> Certain files require UNIX line endings, even though this is a Windows
> system. For this we use .gitattributes.
>
> However, if the .gitattributes file is also checked in to the branch, it
> will not always be honored. I browsed the code a bit, and it seems to
> happen whenever there is an existing .gitattributes file, but the
> checkout adds new files to it. These new files will not get the correct
> line endings (although I'm not sure if it happens *every* time, it could
> depend on the order they are checked out).
>
> I think this should be fairly straightforward to fix, by ensuring that
> if there is a file called .gitattributes in the index of the current
> directory, check it out first, before all the other files that may be
> affected by it. I can produce a patch and testcase for it, but I wanted
> to hear the opinions of some developers in case there is an obvious flaw
> in my solution.
>
> What do you think?
I think there's a general time ordering problem. Say you do the
following commits:
A: add a.txt
B: add a .gitattributes file covering *.txt (say with crlf or any filter)
C: add c.txt
Now, with an empty dir, you do either
1) checkout A, B, C sequentially
2) checkout C
The contents of the checkout will be different in cases 1) and 2):
1) a.txt is checked out out as is, c.txt according to the attributes
2) with current git: probably like 1), with your suggestion: both a.txt
and c.txt filtered according to the attributes.
If you add a file and .gitattributes covering it in the same commit
there is an ordering ambiguity which can be solved (patched away)
easily, but I think the difference between 1) and 2) is still
problematic, and would need to be dealt with.
The main problem seems to be that changing a file like gitattributes can
potentially change (by changing filters) the contents which should be
stored for a different file even if the checkout of that file doesn't
change.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH v3 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 16:40 UTC (permalink / raw)
To: Pieter de Bie; +Cc: git, gitster, sverre
In-Reply-To: <780A42F8-E27C-404A-945C-38C16378EF57@ai.rug.nl>
On Wed, Jan 28, 2009 at 11:18 AM, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> FWIW, I sometimes like to run 'git am', paste in a patch and hit ctrl-d.
>
> I can probably retrain my finger to use 'git am -', but I'm not sure if that
> works (after this patch)? At least it's not mentioned in the manpage.
"git am -" doesn't work (before or after this patch), but "cat | git am" will.
j.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Nicolas Pitre @ 2009-01-28 16:38 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <20090128160900.GJ1321@spearce.org>
On Wed, 28 Jan 2009, Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> >
> > I've been toying with an idea for an alternative solution, and need
> > somebody competent to bounce it around with.
>
> Heh, then we need to wait for Nico... :-)
Hmmm... ehhh... what have I done?
/me tries to walk by innocently without being noticed ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH v3 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Pieter de Bie @ 2009-01-28 16:18 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, gitster, sverre
In-Reply-To: <1233154990-19745-1-git-send-email-jaysoffian@gmail.com>
On Jan 28, 2009, at 3:03 PM, Jay Soffian wrote:
> When git am is called w/o arguments, w/o a patch on stdin and the
> user hits
> ctrl-c, it leaves behind a partially populated $dotest directory.
> After this
> commit, it emits usage when called w/o arguments and w/o a patch on
> stdin.
FWIW, I sometimes like to run 'git am', paste in a patch and hit ctrl-d.
I can probably retrain my finger to use 'git am -', but I'm not sure
if that
works (after this patch)? At least it's not mentioned in the manpage.
- Pieter
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-28 16:16 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <20090128081745.GA2172@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Jan 28, 2009 at 12:05:33AM -0800, Junio C Hamano wrote:
> > Jeff King <peff@peff.net> writes:
> > >
> > > C--D
> > > /
> > > A--B
> > > \
> > > E--F
>
> Don't the other changes have similar parallel use cases? [2/2] also deals
> with tag lookup. Wouldn't you also expect, if you had a tag "T" pointing
> to "E" in the above scenario that "git rev-list T..D" would barf? I
> really think you don't want to ignore missing negations _ever_ unless
> the caller knows that such a miss is really only about optimization and
> not correctness.
Exactly what I just said in my other message.
> Side note:
>
> As you described, we expect to reach this situation from a partial
> transfer. Which means that you don't actually have a _ref_ for "T" (or
> "F"). So it is unlikely to come up in normal use (you would have to
> manually specify the sha1 of a broken portion of the graph).
True, but in the send-pack case we are discussing the remote side
has specified the SHA-1 of broken portions of the graph to us,
and we've taken that into consideration. So we have to fix that
assumption we've made.
> But what is more important is that your repository _is_ corrupted,
Depends. If the SHA-1 came from the remote side during send-pack,
it doesn't matter that we have a broken chain along that path,
it may have been a dumb transport fetch that was interrupted.
Our local repository isn't corrupt, it just has some extra crap
laying around that hasn't gc'd yet.
If the SHA-1 came from the user, then it depends on the context
of why the user is giving it to us. In pretty much every case,
yes, its a corruption and we should be aborting. :-)
Actually, the only time where it *isn't* a corruption is when its
input to "git bundle create A.bdl ... -not $SOMEBADID" as that is
the exact same thing as coming from the other side via send-pack.
> I
> think we are losing an important method by which the user finds out. Git
> is usually very good at informing you of a problem in the repo early,
> and I think unconditionally ignoring missing objects would lose that.
Yup, I agree. But as you and Junio have already pointed out, C Git
can miss some types of corruption because the revision machinary has
some gaps. *sigh*
I'd really like to see those gaps closed. But I don't have a good
enough handle on the code structure of the C Git revision machinary
to do that myself in a short period of time. I know JGit's well...
but that's only because I wrote it. ;-)
Its now on my wish list of things I wish I had time for in C Git.
But perhaps someone who is more familiar with the revision machinary
will get to it first.
--
Shawn.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-28 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, PJ Hyett, Johannes Schindelin, git
In-Reply-To: <7vd4e7x5ov.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> I've been toying with an idea for an alternative solution, and need
> somebody competent to bounce it around with.
Heh, then we need to wait for Nico... :-)
> pack-objects ends up doing eventually
>
> rev-list --objects $send1 $send2 $send3 ... --not $have1 $have2 ...
>
> which lists commits and associated objects reachable from $sendN,
> excluding the ones that are reachable from $haveN.
>
> The tentative solution Björn Steinbrink and I came up with excludes
> missing commit from $haveN to avoid rev-list machinery to barf, but it
> violates the ref-object contract as I explained to Björn in my other
> message.
Oh, OK, I now _finally_ understand what you were trying to say
by the reachability thing. I kept scratching my head trying to
understand you, and was going to say something stupid on list;
but waited because I just didn't get what the big deal was...
Its the crash in rev-list that you were worried about.
> Checking if each commit is reachable from any of the refs is quite
> expensive, and it would especially be so if it is done once per ".have"
> and real ref we receive from the other end.
Yup.
> An alternative is to realize that rev-list traversal already does
> something quite similar to what is needed to prove if these ".have"s are
> reachable from refs when listing the reachable objects. This computation
> is what it needs to do anyway, so if we teach rev-list to ignore missing
> or broken chain while traversing negative refs, we do not have to incur
> any overhead over existing code.
EXACTLY.
JGit does this.
The functional equivilant of rev-list in JGit will by default
throw an exception if any object is missing when we try to walk it.
That includes things we've painted UNINTERESTING, as it is a sure
sign of repository corruption.
However; our equivilant of pack-objects can toggle what you are
calling "ignore-missing-negative" when it starts enumeration.
Any UNINTERESTING object which is missing or failed to parse is
simply tossed aside. Yes, the pack may be larger than necessary
like in Peff's example of:
Q-R
/
D--E
\
A-C
If the other side has C reachable, we are pushing R, and we have
C but are missing A, we'll "over push" D-E, but its still a clean
and valid push. Its no worse than we were before the ".have" came
about, or if C hadn't been downloaded locally at all. (Of course
your tell-me-more extension would help fix this over-push, but lets
not get off topic.)
IMHO, this corruption of A is harmless if C isn't reachable.
It isn't really local corruption unless C was reachable by a ref.
But we don't tend to see much corruption like that, and if it did
exist, it would show up during *other* operations that access a
larger set of local refs, such as "git gc".
> I have a mild suspicion that it may even be the right thing to ignore them
> unconditionally, and it might even match the intention of Linus's original
> code. That would make many hunks in this patch much simpler.
I don't think its right to ignore broken UNINTERESTING chains all
of the time. Today we would see fatal errors if I asked for
git log R ^C
and A was missing, but R and C are both local refs. I still want
to see that fatal error. Its a local corruption that should be
raised quickly to the user. In fact by A missing we'd compute the
wrong result and produce D-E too, which is wrong.
IMHO, the *only* time this missing uninteresting A is safe is
during send-pack, upload-pack, or bundle creation, where you are
bringing the other side up to R by transferring any amount of data
necessary to reach that goal. Which is why JGit enables this.
(Though at the API level we do let the caller flag if they want
the error to be fatal instead, but AFAIK nobody sets it for "fatal".)
FWIW, Linus' most recent message on this thread about hoisting the
UNINTERESTING test up sooner makes sense too.
> The evidences behind this suspicion are found in a handful of places in
> revision.c. mark_blob_uninteresting() does not complain if the caller
> fails to find the blob. mark_tree_uninteresting() does not, either.
> mark_parents_uninteresting() does not, either, and it even has a comment
> that strongly suggests the original intention was not to care about
> missing UNINTERESTING objects.
That feels wrong to me... given the "git log R ^C" example I give above.
--
Shawn.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Linus Torvalds @ 2009-01-28 15:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, PJ Hyett, Johannes Schindelin, git
In-Reply-To: <7vvdrzvpwd.fsf@gitster.siamese.dyndns.org>
On Tue, 27 Jan 2009, Junio C Hamano wrote:
>
> - When digging deeper into the ancestry chain of a commit that is already
> painted as UNINTERESTING, in order to paint its parents UNINTERESTING,
> we barfed if parse_parent() for a parent commit object failed. We can
> ignore such a parent commit object.
Wouldn't it be better to still mark it UNINTERESTING too?
> @@ -480,7 +483,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
> struct commit *p = parent->item;
> parent = parent->next;
> if (parse_commit(p) < 0)
> - return -1;
> + continue;
> p->object.flags |= UNINTERESTING;
> if (p->parents)
> mark_parents_uninteresting(p);
IOW, move that
p->object.flags |= UNINTERESTING;
to before parse_commit(). That's assuming 'parent' is never NULL, of
course.
Side note: parse_commit() is still going to print out the error message
if the object is missing ("Could not read %s"). I guess that's fine, but
if you really want to make this a "not an error at all" condition...
Linus
^ permalink raw reply
* Honoring a checked out gitattributes file
From: Kristian Amlie @ 2009-01-28 15:25 UTC (permalink / raw)
To: git
Hi!
We currently use msysGit in our company test farm to checkout the latest
development branch and do autotests. However, we have one problem:
Certain files require UNIX line endings, even though this is a Windows
system. For this we use .gitattributes.
However, if the .gitattributes file is also checked in to the branch, it
will not always be honored. I browsed the code a bit, and it seems to
happen whenever there is an existing .gitattributes file, but the
checkout adds new files to it. These new files will not get the correct
line endings (although I'm not sure if it happens *every* time, it could
depend on the order they are checked out).
I think this should be fairly straightforward to fix, by ensuring that
if there is a file called .gitattributes in the index of the current
directory, check it out first, before all the other files that may be
affected by it. I can produce a patch and testcase for it, but I wanted
to hear the opinions of some developers in case there is an obvious flaw
in my solution.
What do you think?
--
Kristian Amlie
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-28 15:03 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Mike Ralphson, git
In-Reply-To: <20090128074204.GA31951@coredump.intra.peff.net>
On Jan 28, 2009, at 1:42 AM, Jeff King wrote:
> On Tue, Jan 27, 2009 at 11:37:21PM -0800, Junio C Hamano wrote:
>
>>>> Just to be sure we are on the same page. My directory structure
>>>> has a
>>>> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is
>>>> the
>>>> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
>>>> then do: ../../src/git-1.6.1/configure <options> After this
>>>> completes, you can do "make".
>>>
>>> I don't see how this would work without automake support, which
>>> git does
>>> not have.
>>
>> ... nor want to have ;-).
>
> Heh. Yes, in case there was any confusion: I don't want my statement
> in
> any way to be construed as a suggestion to support automake.
>
> I would not be opposed to it if it somehow enhanced some users'
> experience without bothering people who didn't want to touch it (like
> the way that autoconf support is implemented). But I don't see how
> that
> would be possible.
Thats fine. I didn't know if this was a "known" situation or not so I
just mentioned it.
As I mentioned, most open source code supports this style of build. I
have no idea
what it would take to get it to work.
^ permalink raw reply
* [PATCH v3 2/2] git-am: minor cleanups
From: Jay Soffian @ 2009-01-28 15:03 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
In-Reply-To: <1233154990-19745-1-git-send-email-jaysoffian@gmail.com>
Update usage statement to remove a no-longer supported option, and to hide two
options (one a no-op, one internal) unless --help-all is used.
Use "test -t 0" instead of "tty -s" to detect when stdin is a terminal. (test
-t 0 is used elsewhere in git-am and in other git shell scripts, tty -s is
not, and appears to be deprecated by POSIX)
Use "test ..." instead of "[ ... ]" and "die <msg>" instead of "echo <msg>
>&2; exit 1" to be consistent with rest of script.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Change from v2: mention who deprecated "tty -s" in commit message.
git-am.sh | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 92a64b2..670fc02 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -8,9 +8,8 @@ OPTIONS_SPEC="\
git am [options] [<mbox>|<Maildir>...]
git am [options] (--resolved | --skip | --abort)
--
-d,dotest= (removed -- do not use)
i,interactive run interactively
-b,binary (historical option -- no-op)
+b,binary* (historical option -- no-op)
3,3way allow fall back on 3way merging if needed
s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
@@ -24,7 +23,7 @@ resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
abort restore the original branch and abort the patching operation.
-rebasing (internal use for git-rebase)"
+rebasing* (internal use for git-rebase)"
. git-sh-setup
prefix=$(git rev-parse --show-prefix)
@@ -204,7 +203,7 @@ then
# unreliable -- stdin could be /dev/null for example
# and the caller did not intend to feed us a patch but
# wanted to continue unattended.
- tty -s
+ test -t 0
;;
*)
false
@@ -281,10 +280,7 @@ fi
case "$resolved" in
'')
files=$(git diff-index --cached --name-only HEAD --) || exit
- if [ "$files" ]; then
- echo "Dirty index: cannot apply patches (dirty: $files)" >&2
- exit 1
- fi
+ test "$files" && die "Dirty index: cannot apply patches (dirty: $files)"
esac
if test "$(cat "$dotest/utf8")" = t
--
1.6.1.224.gb56c
^ permalink raw reply related
* [PATCH v3 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 15:03 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
When git am is called w/o arguments, w/o a patch on stdin and the user hits
ctrl-c, it leaves behind a partially populated $dotest directory. After this
commit, it emits usage when called w/o arguments and w/o a patch on stdin.
Noticed by Sverre Rabbelier
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Change from v2: make Junio happy by no longer removing $dotest if git-am is
interupted while mailsplit is running.
git-am.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b1c05c9..92a64b2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -254,6 +254,7 @@ else
done
shift
fi
+ test $# = 0 && test -t 0 && usage
git mailsplit -d"$prec" -o"$dotest" -b -- "$@" > "$dotest/last" || {
rm -fr "$dotest"
exit 1
--
1.6.1.224.gb56c
^ permalink raw reply related
* Re: [PATCH] Add --ff-only flag to git-merge
From: Sverre Rabbelier @ 2009-01-28 14:35 UTC (permalink / raw)
To: Yuval Kogman; +Cc: git
In-Reply-To: <1233147238-30082-1-git-send-email-nothingmuch@woobling.org>
On Wed, Jan 28, 2009 at 13:53, Yuval Kogman <nothingmuch@woobling.org> wrote:
> This patch adds an --ff-only flag to git-merge. When specified git-merge
> will exit with an error whenver a merge will not be a simple fast
> forward, similar to the default behavior of git push.
I like! This calls for a new alias 'git config alias.integrate "merge
--no-ff"', thanks!
*hopes this hits next soon*
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 14:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sverre
In-Reply-To: <7vhc3kxdwm.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 11:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> + test $# = 0 && test -t 0 && usage
>
> Sorry to be dense. Why isn't your patch the above single liner?
>
"Also ensure that $dotest is cleaned up if user manages to interupt mailsplit
while it is processing input, but not if mailsplit exits non-zero due to
error."
j.
^ permalink raw reply
* Re: [PATCH v2 2/2] git-am: minor cleanups
From: Jay Soffian @ 2009-01-28 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sverre
In-Reply-To: <7vd4e8xdva.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 11:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Use "test -t 0" instead of deprecated "tty -s" to detect when stdin is a
>> terminal.
>
> Who deprecated it?
I believe it's IEEE Std 1003.2-1992 / POSIX.2. I found the initial
reference in the BSD/OS X man page[1], but google also found me other
references [2,3]. Also, elsewhere git uses "test -t 0", not "tty -s".
[1] http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man1/tty.1.html
(The -s option is deprecated in favor of the ``test -t 0'' command.)
[2] http://docs.sun.com/app/docs/doc/816-5165/tty-1?a=view
(Portable applications should use test -t.)
[3] http://opengroup.org/onlinepubs/007908799/xcu/tty.html
(Portable applications should use test -t 0.)
j.
^ permalink raw reply
* Re: [PATCH] Add --ff-only flag to git-merge
From: Yuval Kogman @ 2009-01-28 13:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901281425180.3586@pacific.mpi-cbg.de>
2009/1/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> If you compare the two if() lines, you will see that you mixed style.
Thanks,
I will be fixing it here:
http://github.com/nothingmuch/git/tree/ff-only
before I send a new version, as I likely screwed up many things, not
just that =)
^ permalink raw reply
* Re: [PATCH] Add --ff-only flag to git-merge
From: Johannes Schindelin @ 2009-01-28 13:26 UTC (permalink / raw)
To: Yuval Kogman; +Cc: git
In-Reply-To: <1233147238-30082-1-git-send-email-nothingmuch@woobling.org>
Hi,
On Wed, 28 Jan 2009, Yuval Kogman wrote:
> @@ -1012,6 +1015,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> finish(o->sha1, msg.buf);
> drop_save();
> return 0;
> + } else if ( only_fast_forward ) {
> + printf("Merge is non fast forward, aborting.\n");
> + return 1;
> } else if (!remoteheads->next && common->next)
If you compare the two if() lines, you will see that you mixed style.
Ciao,
Dscho
^ permalink raw reply
* Re: (beginner) git rm
From: Theodore Tso @ 2009-01-28 13:03 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Zabre, git
In-Reply-To: <49804D41.3010801@dbservice.com>
On Wed, Jan 28, 2009 at 01:19:13PM +0100, Tomas Carnecky wrote:
>
> Oops, sorry. git checkout HEAD -- d.txt
> You have to tell which version of d.txt you want. In your case the
> version in HEAD.
>
I use this command enough that I have this defined as an alias in my
~/.gitconfig file. Try running this command:
git config --global alias.revert-file "checkout HEAD --"
Now you will be able to do this:
git revert-file d.txt
This is also useful when I've edited d.txt, and decided that I didn't
go about it the right away, and so I want to revert my edits.
- Ted
^ permalink raw reply
* [PATCH] Add --ff-only flag to git-merge
From: Yuval Kogman @ 2009-01-28 12:53 UTC (permalink / raw)
To: git; +Cc: Yuval Kogman
This patch adds an --ff-only flag to git-merge. When specified git-merge
will exit with an error whenver a merge will not be a simple fast
forward, similar to the default behavior of git push.
---
builtin-merge.c | 6 ++++++
t/t7600-merge.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e4555b0..d37423b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -44,6 +44,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, option_log, squash;
static int option_commit = 1, allow_fast_forward = 1;
static int allow_trivial = 1, have_message;
+static int only_fast_forward;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
static unsigned char head[20], stash[20];
@@ -167,6 +168,8 @@ static struct option builtin_merge_options[] = {
"perform a commit if the merge succeeds (default)"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast forward (default)"),
+ OPT_BOOLEAN(0, "ff-only", &only_fast_forward,
+ "allow only fast forward"),
OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
"merge strategy to use", option_parse_strategy),
OPT_CALLBACK('m', "message", &merge_msg, "message",
@@ -1012,6 +1015,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
finish(o->sha1, msg.buf);
drop_save();
return 0;
+ } else if ( only_fast_forward ) {
+ printf("Merge is non fast forward, aborting.\n");
+ return 1;
} else if (!remoteheads->next && common->next)
;
/*
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index e5b210b..6c2febc 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -234,6 +234,8 @@ test_expect_success 'reject non-strategy with a git-merge-foo name' '
test_must_fail git merge -s index c1
'
+test_debug 'gitk --all'
+
test_expect_success 'merge c0 with c1' '
git reset --hard c0 &&
git merge c1 &&
@@ -243,6 +245,15 @@ test_expect_success 'merge c0 with c1' '
test_debug 'gitk --all'
+test_expect_success 'merge c0 with c1 (fast forward only)' '
+ git reset --hard c0 &&
+ git merge --ff-only c1 &&
+ verify_merge file result.1 &&
+ verify_head "$c1"
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2' '
git reset --hard c1 &&
test_tick &&
@@ -253,6 +264,14 @@ test_expect_success 'merge c1 with c2' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2' '
+ git reset --hard c1 &&
+ test_tick &&
+ test_must_fail git merge --ff-only c2
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 and c3' '
git reset --hard c1 &&
test_tick &&
@@ -263,6 +282,14 @@ test_expect_success 'merge c1 with c2 and c3' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 and c3 (fast forward only' '
+ git reset --hard c1 &&
+ test_tick &&
+ test_must_fail git merge --ff-only c2 c3
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c0 with c1 (no-commit)' '
git reset --hard c0 &&
git merge --no-commit c1 &&
@@ -470,6 +497,15 @@ test_expect_success 'merge c1 with c0, c2, c0, and c1' '
test_debug 'gitk --all'
+test_expect_success 'merge fast forward only' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "" &&
+ test_tick &&
+ test_must_fail git merge --ff-only c0 c2 c0 c1
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c0, c2, c0, and c1' '
git reset --hard c1 &&
git config branch.master.mergeoptions "" &&
@@ -481,6 +517,15 @@ test_expect_success 'merge c1 with c0, c2, c0, and c1' '
test_debug 'gitk --all'
+test_expect_success 'merge fast forward only' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "" &&
+ test_tick &&
+ test_must_fail git merge --ff-only c1 c2
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c1 and c2' '
git reset --hard c1 &&
git config branch.master.mergeoptions "" &&
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Johannes Schindelin @ 2009-01-28 12:43 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <20090128042814.GA18216@coredump.intra.peff.net>
Hi,
On Tue, 27 Jan 2009, Jeff King wrote:
> On Tue, Jan 27, 2009 at 05:42:03PM +0100, Johannes Schindelin wrote:
>
> > > We want to catch failures of test-chmtime; but since it appears in a
> > > pipe, we cannot access its exit code. Therefore, we at least make sure
> > > that it prints time stamps of all files that are passed on its command
> > > line.
> >
> > I use this trick in my valgrind series:
> >
> > ($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
> > test 0 = "$(cat exit.code)"
>
> Oh, that's far too readable. How about:
>
> exec 3>&1
> status=$( ( ($PROGRAM ; echo $? >&4) | $OTHER_PROGRAM >&3) 4>&1 )
> exec 3>&-
>
> But seriously, I think if we are talking about tests, then
>
> $PROGRAM >output &&
> $OTHER_PROGRAM <output
>
> is very clear to read, and as a bonus makes "output" accessible for
> viewing when the test breaks.
The real problem is that in my case, OTHER_PROGRAM=tee.
But you're right, Hannes was talking about tests, where it might
even make sense to have a record of what was passed between the
two programs.
Ciao,
Dscho
^ permalink raw reply
* Re: (beginner) git rm
From: Tomas Carnecky @ 2009-01-28 12:19 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233144045221-2231849.post@n2.nabble.com>
On 01/28/2009 01:00 PM, Zabre wrote:
>
> Tomas Carnecky wrote:
>> Do you mean 'undelete' a file? git checkout d.txt - That restores the
>> file in the working tree and resets the index just for that file.
>>
>
> Hi Tom,
> (thank you for your interest in my newbie problems)
>
> yes that's what I mean : 'undelete' a file, after a "git rm d.txt".
> But I did not manage to apply your solution succesfully :
> $ git rm d.txt
> $ ls
> a.txt b.txt c.txt
> $ git status
> # On branch new
> # Changes to be committed:
> # (use "git reset HEAD<file>..." to unstage)
> #
> # deleted: d.txt
> #
> $ git checkout d.txt
> error: pathspec 'mamma.txt' did not match any file(s) known to git.
> Did you forget to 'git add'?
Oops, sorry. git checkout HEAD -- d.txt
You have to tell which version of d.txt you want. In your case the
version in HEAD.
tom
^ 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