* Re: suggestion for a simple addition: git update-ref --ff-only
From: Jeff King @ 2013-03-02 1:10 UTC (permalink / raw)
To: David Madore; +Cc: git
In-Reply-To: <20130301231859.GA334@achernar.madore.org>
On Sat, Mar 02, 2013 at 12:18:59AM +0100, David Madore wrote:
> I'd like to suggest a very simple, but IMHO quite useful, additional
> option to git-update-ref: an option --ff-only which would cause the
> command to refuse unless the current ref is an ancestor of the new
> one.
>
> The reason I think it would be useful: I occasionally wish to perform
> a trivial (i.e., fast-forward) merge of some branch into another
> (e.g., after a git-fetch) without checking it out. Now git-update-ref
> is perfect for that, but there is always the possibility of getting
> something wrong (which one would not have with git merge --ff-only,
> but the latter requires checking out the branch), and this option
> would avoid tedious verifications.
The update-ref command is plumbing, which is supposed to do one small,
well-defined job. But you can compose many plumbing commands to do what
you want:
# input
ref=refs/heads/master
new=$some_sha1
# where are we now?
old=`git rev-parse --verify $ref` || exit 1
# is it a fast-forward?
if ! git merge-base --is-ancestor $old $new; then
echo >&2 "Not a fast-forward"
exit 1
fi
# update it; we do not have to worry about race conditions because
# update-ref will abort if somebody touched the ref in the meantime
git update-ref $ref $new $old
Yes, it's three commands instead of one, but it's much more flexible
(you get to write your own message, you can use the same "merge-base" to
handle the "already up to date" case, etc).
-Peff
^ permalink raw reply
* Re: [BUG?] am --abort on null cache entries fails
From: Jeff King @ 2013-03-02 0:57 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <51314D40.9030209@codeaurora.org>
On Fri, Mar 01, 2013 at 04:52:16PM -0800, Stephen Boyd wrote:
> I was trying git am -3 with a patch that touched files that didn't exist
> in the branch I was on. Obviously it failed badly, so I wanted to abort
> out of the git am state with git am --abort. Unfortunately, it seems
> that git am --abort in this scenario fails with this error:
>
> error: cache entry has null sha1: <non-existant-file>
>
> and then leaves the file in my working tree untracked. This didn't used
> to happen, so I bisected it down to this commit
>
> commit 4337b5856f88f18da47c176e3cbc95a35627044c
> Author: Jeff King <peff@peff.net>
> Date: Sat Jul 28 11:05:24 2012 -0400
> do not write null sha1s to on-disk index
>
> Which definitely introduced that error message.
Yep. It's a bug, but that commit does not introduce it; it actually just
notices the bug earlier.
> How do we fix this?
See this thread for the current discussion and some possible fixes:
http://thread.gmane.org/gmane.comp.version-control.git/217172
-Peff
^ permalink raw reply
* Re: two-way merge corner case bug
From: Jeff King @ 2013-03-02 0:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9qmel4s.fsf@alter.siamese.dyndns.org>
On Fri, Mar 01, 2013 at 03:49:23PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> I actually was wondering if we can remove that sole uses of two-way
> >> merge with --reset -u from "git am" and replace them with something
> >> else. But we do want to keep local change that existed before "am"
> >> started, so we cannot avoid use of two-way merge, I guess...
> >
> > Yeah, I think that is a case we definitely want to keep, as it means any
> > intermediate work done by the user in applying the patch is not lost.
>
> I am not sure what you mean by "intermediate" here. When the user
> attempts to resolve conflict in a path manually and gives up, we do
> want to revert changes to such a path to that of HEAD.
I thought we left it unchanged intentionally, but I cannot seem to find
the conversation I am thinking of. I did find this:
http://thread.gmane.org/gmane.comp.version-control.git/164002
But that is not about "save the intermediate work done on applying the
series", but rather to help with this case:
1. You "git am" a series. It doesn't apply.
2. You get distracted and work on something else, forgetting that the
dotest directory is sitting there.
3. Time passes.
4. You try to "git am" a new series. An "am" is already in progress,
so you are advised to "git am --abort".
At that point you do not want to reset the commit to the original head
(which was fixed by 7b3b7e3), but you do not necessarily want to reset
the working tree contents either. We leave them in the name of safety
and letting the user deal with it.
> Clarifying the semantics of "--reset" needs to be done carefully.
>
> I think any difference "git diff --cached" shows are fair game to
> revert to HEAD. In the earlier example, path "Z" that was created
> by recursive merge in an attempt to rename "A" should be removed,
> and path "A" should be recreated to that of HEAD, as we know at the
> point of "am --skip/--abort" that these two paths were involved in
> the recursive merge invoked by the patch application process (that
> is the only possible reason why these are different in the index
> from HEAD). Also any conflicting entries can only come from
> three-way merge and they should be reverted to that of HEAD.
>
> On the other hand, the paths that appear in "git diff" (except for
> those that appear in "git diff --cached", which we will revert to
> HEAD following the logic of the previous paragraph) must be kept.
> They are changes that were already present in the working tree
> before the user decided to accept a trivial patch via "am" that does
> not overlap with what the user was doing. We allow a dirty working
> tree but disallow a dirty index when "git am" starts, exactly
> because we want to ensure this property.
>
> By doing both of the above, we should be able to satisfy the user
> who uses "am --abort/--skip", in order to restore paths that were
> involved in the failed attempt to three-way merge to revert back to
> that of HEAD, while keeping unrelated changes that were present
> before "am" started.
I think that makes sense, but I don't think we have a read-tree mode to
do that in one pass, do we? Not that we can't add one if we need.
-Peff
^ permalink raw reply
* [BUG?] am --abort on null cache entries fails
From: Stephen Boyd @ 2013-03-02 0:52 UTC (permalink / raw)
To: git; +Cc: Jeff King
Hi,
I was trying git am -3 with a patch that touched files that didn't exist
in the branch I was on. Obviously it failed badly, so I wanted to abort
out of the git am state with git am --abort. Unfortunately, it seems
that git am --abort in this scenario fails with this error:
error: cache entry has null sha1: <non-existant-file>
and then leaves the file in my working tree untracked. This didn't used
to happen, so I bisected it down to this commit
commit 4337b5856f88f18da47c176e3cbc95a35627044c
Author: Jeff King <peff@peff.net>
Date: Sat Jul 28 11:05:24 2012 -0400
do not write null sha1s to on-disk index
Which definitely introduced that error message. How do we fix this?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Jeff King @ 2013-03-02 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: William Giokas, git
In-Reply-To: <7v1ubyek9n.fsf@alter.siamese.dyndns.org>
On Fri, Mar 01, 2013 at 04:08:04PM -0800, Junio C Hamano wrote:
> > +static int maildir_filename_cmp(const char *a, const char *b)
> > +{
> > + while (1) {
>
> It is somewhat funny that we do not need to check !*a or !*b in this
> loop. As long as readdir() does not return duplicates, we won't be
> comparing the same strings with this function, and we won't read
> past '\0' at the end of both a and b at the same time.
Ugh, thanks for catching. I had structured this differently at first
with a while(1), and then after refactoring it forgot to update the loop
condition. Even if it is fine without duplicates, we should not rely on
that not to cause an infinite loop (in case the function is ever used
again). But moreover, you can trigger the problem even now, since we
would parse "foo_0123" and "foo_123" as equivalent, and hit the NUL.
I think this needs squashed in:
diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
index 772c668..1ddbff4 100644
--- a/builtin/mailsplit.c
+++ b/builtin/mailsplit.c
@@ -132,7 +132,7 @@ static int maildir_filename_cmp(const char *a, const char *b)
static int maildir_filename_cmp(const char *a, const char *b)
{
- while (1) {
+ while (*a && *b) {
if (isdigit(*a) && isdigit(*b)) {
long int na, nb;
na = strtol(a, (char **)&a, 10);
@@ -148,6 +148,7 @@ static int maildir_filename_cmp(const char *a, const char *b)
b++;
}
}
+ return *a - *b;
}
static int split_maildir(const char *maildir, const char *dir,
-Peff
^ permalink raw reply related
* Re: [bug report] git-am applying maildir patches in reverse
From: Jeff King @ 2013-03-02 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: William Giokas, git
In-Reply-To: <7v621aekr0.fsf@alter.siamese.dyndns.org>
On Fri, Mar 01, 2013 at 03:57:39PM -0800, Junio C Hamano wrote:
> > The epoch_seconds are the time of writing into the maildir. They will
> > typically all be the same, unless your system is very slow, or you are
> > writing a really long patch series. The PID likewise should be the same
> > for a given series. It's the sequence number that is the interesting bit
> > to sort numerically (for mutt, anyway; ditto for dovecot).
>
> OK, so as long as the user tells mutt what order the messages need
> to be written in when choosing these 16 patches, tiebreaking with
> the sequence number would be sufficient.
>
> Is it easy to tell that to mutt, though, given that the patches
> arrive in random order, not in the order they were sent?
Yes. You can either write one at a time, or you can tag several and
write them with a single command. In the latter case, it writes them out
according to the currently displayed sort order. The usual threaded
display gets it right for delivered messages (it shows them in date
order within the thread), and you can use sort-by-subject to override it
if you are working with munged timestamps.
> I would imagine that you sort the messages in your inbox, select a
> group of messages and tell mutt to write them out to a (new) empty
> maildir, and at that point mutt writes them out in the order you used
> to sort them---is that how it is supposed to work?
>
> Or are you assuming that the user chooses 1/16, tells mutt to write it
> out, chooses 2/16, tells mut to write that out, iterating it 16 times
> to write out a 16-patch series?
Right. The latter probably already works (unless you are so fast that
you write out multiple messages in one second), but I would expect most
people would tag and then save all at once.
-Peff
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Junio C Hamano @ 2013-03-02 0:08 UTC (permalink / raw)
To: Jeff King; +Cc: William Giokas, git
In-Reply-To: <20130301233548.GA13422@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
> index 2d43278..772c668 100644
> --- a/builtin/mailsplit.c
> +++ b/builtin/mailsplit.c
> @@ -130,6 +130,26 @@ static int populate_maildir_list(struct string_list *list, const char *path)
> return 0;
> }
>
> +static int maildir_filename_cmp(const char *a, const char *b)
> +{
> + while (1) {
It is somewhat funny that we do not need to check !*a or !*b in this
loop. As long as readdir() does not return duplicates, we won't be
comparing the same strings with this function, and we won't read
past '\0' at the end of both a and b at the same time.
> + if (isdigit(*a) && isdigit(*b)) {
> + long int na, nb;
> + na = strtol(a, (char **)&a, 10);
> + nb = strtol(b, (char **)&b, 10);
> + if (na != nb)
> + return na - nb;
> + /* strtol advanced our pointers */
> + }
> + else {
> + if (*a != *b)
> + return *a - *b;
> + a++;
> + b++;
> + }
> + }
> +}
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Junio C Hamano @ 2013-03-01 23:57 UTC (permalink / raw)
To: Jeff King; +Cc: William Giokas, git
In-Reply-To: <20130301233548.GA13422@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Mar 01, 2013 at 03:24:42PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote:
>> > ...
>> >> The maildir spec explicitly says that readers should not make
>> >> assumptions about the content of the filenames. Mutt happens to write
>> >> them as:
>> >>
>> >> ${epoch_seconds}.${pid}_${seq}.${host}
>> >>
>> >> so in practice, sorting them kind of works. Except that ...
>> >> << it does not work >> ...
>> > That ordering is not necessarily useful.
>> > ...
>> > So it is somewhat against the maildir spec, but I think in practice it
>> > would help.
>>
>> I do not think it would help, unless these epoch_seconds are the
>> sender timestamps. And the number of digits in epoch-seconds for
>> recent messages would be the same, so ordering textually would be
>> sufficient if ordering by timestamp were.
>
> The epoch_seconds are the time of writing into the maildir. They will
> typically all be the same, unless your system is very slow, or you are
> writing a really long patch series. The PID likewise should be the same
> for a given series. It's the sequence number that is the interesting bit
> to sort numerically (for mutt, anyway; ditto for dovecot).
OK, so as long as the user tells mutt what order the messages need
to be written in when choosing these 16 patches, tiebreaking with
the sequence number would be sufficient.
Is it easy to tell that to mutt, though, given that the patches
arrive in random order, not in the order they were sent? I would
imagine that you sort the messages in your inbox, select a group of
messages and tell mutt to write them out to a (new) empty maildir,
and at that point mutt writes them out in the order you used to sort
them---is that how it is supposed to work?
Or are you assuming that the user chooses 1/16, tells mutt to write
it out, chooses 2/16, tells mut to write that out, iterating it 16
times to write out a 16-patch series?
I can see why your patch would _not_ hurt, but I cannot tell how
much it would help without knowing that part of the detail.
> -- >8 --
> Subject: [PATCH] mailsplit: sort maildir filenames more cleverly
>
> A maildir does not technically record the order in which
> items were placed into it. That means that when applying a
> patch series from a maildir, we may get the patches in the
> wrong order. We try to work around this by sorting the
> filenames. Unfortunately, this may or may not work depending
> on the naming scheme used by the writer of the maildir.
>
> For instance, mutt will write:
>
> ${epoch_seconds}.${pid}_${seq}.${host}
>
> where we have:
>
> - epoch_seconds: timestamp at which entry was written
> - pid: PID of writing process
> - seq: a sequence number to ensure uniqueness of filenames
> - host: hostname
>
> None of the numbers are zero-padded. Therefore, when we sort
> the names as byte strings, entries that cross a digit
> boundary (e.g., 10) will sort out of order. In the case of
> timestamps, it almost never matters (because we do not cross
> a digit boundary in the epoch time very often these days).
> But for the sequence number, a 10-patch series would be
> ordered as 1, 10, 2, 3, etc.
>
> To fix this, we can use a custom sort comparison function
> which traverses each string, comparing chunks of digits
> numerically, and otherwise doing a byte-for-byte comparison.
> That would sort:
>
> 123.456_1.bar
> 123.456_2.bar
> ...
> 123.456_10.bar
>
> according to the sequence number. Since maildir does not
> define a filename format, this is really just a heuristic.
> But it happens to work for mutt, and there is a reasonable
> chance that it will work for other writers, too (at least as
> well as a straight sort).
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> builtin/mailsplit.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
> index 2d43278..772c668 100644
> --- a/builtin/mailsplit.c
> +++ b/builtin/mailsplit.c
> @@ -130,6 +130,26 @@ static int populate_maildir_list(struct string_list *list, const char *path)
> return 0;
> }
>
> +static int maildir_filename_cmp(const char *a, const char *b)
> +{
> + while (1) {
> + if (isdigit(*a) && isdigit(*b)) {
> + long int na, nb;
> + na = strtol(a, (char **)&a, 10);
> + nb = strtol(b, (char **)&b, 10);
> + if (na != nb)
> + return na - nb;
> + /* strtol advanced our pointers */
> + }
> + else {
> + if (*a != *b)
> + return *a - *b;
> + a++;
> + b++;
> + }
> + }
> +}
> +
> static int split_maildir(const char *maildir, const char *dir,
> int nr_prec, int skip)
> {
> @@ -139,6 +159,8 @@ static int split_maildir(const char *maildir, const char *dir,
> int i;
> struct string_list list = STRING_LIST_INIT_DUP;
>
> + list.cmp = maildir_filename_cmp;
> +
> if (populate_maildir_list(&list, maildir) < 0)
> goto out;
^ permalink raw reply
* Re: two-way merge corner case bug
From: Junio C Hamano @ 2013-03-01 23:49 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130301230845.GA7317@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> I actually was wondering if we can remove that sole uses of two-way
>> merge with --reset -u from "git am" and replace them with something
>> else. But we do want to keep local change that existed before "am"
>> started, so we cannot avoid use of two-way merge, I guess...
>
> Yeah, I think that is a case we definitely want to keep, as it means any
> intermediate work done by the user in applying the patch is not lost.
I am not sure what you mean by "intermediate" here. When the user
attempts to resolve conflict in a path manually and gives up, we do
want to revert changes to such a path to that of HEAD.
Clarifying the semantics of "--reset" needs to be done carefully.
I think any difference "git diff --cached" shows are fair game to
revert to HEAD. In the earlier example, path "Z" that was created
by recursive merge in an attempt to rename "A" should be removed,
and path "A" should be recreated to that of HEAD, as we know at the
point of "am --skip/--abort" that these two paths were involved in
the recursive merge invoked by the patch application process (that
is the only possible reason why these are different in the index
from HEAD). Also any conflicting entries can only come from
three-way merge and they should be reverted to that of HEAD.
On the other hand, the paths that appear in "git diff" (except for
those that appear in "git diff --cached", which we will revert to
HEAD following the logic of the previous paragraph) must be kept.
They are changes that were already present in the working tree
before the user decided to accept a trivial patch via "am" that does
not overlap with what the user was doing. We allow a dirty working
tree but disallow a dirty index when "git am" starts, exactly
because we want to ensure this property.
By doing both of the above, we should be able to satisfy the user
who uses "am --abort/--skip", in order to restore paths that were
involved in the failed attempt to three-way merge to revert back to
that of HEAD, while keeping unrelated changes that were present
before "am" started.
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Jeff King @ 2013-03-01 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: William Giokas, git
In-Reply-To: <7vlia6em9x.fsf@alter.siamese.dyndns.org>
On Fri, Mar 01, 2013 at 03:24:42PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote:
> > ...
> >> The maildir spec explicitly says that readers should not make
> >> assumptions about the content of the filenames. Mutt happens to write
> >> them as:
> >>
> >> ${epoch_seconds}.${pid}_${seq}.${host}
> >>
> >> so in practice, sorting them kind of works. Except that ...
> >> << it does not work >> ...
> > That ordering is not necessarily useful.
> > ...
> > So it is somewhat against the maildir spec, but I think in practice it
> > would help.
>
> I do not think it would help, unless these epoch_seconds are the
> sender timestamps. And the number of digits in epoch-seconds for
> recent messages would be the same, so ordering textually would be
> sufficient if ordering by timestamp were.
The epoch_seconds are the time of writing into the maildir. They will
typically all be the same, unless your system is very slow, or you are
writing a really long patch series. The PID likewise should be the same
for a given series. It's the sequence number that is the interesting bit
to sort numerically (for mutt, anyway; ditto for dovecot).
The patch below seems to fix the issue for me with mutt. It's possible
that it regresses another case (which has numbers, but really wants them
sorted as byte strings), but I find that unlikely. If you're
zero-padding your numbers this will still work, and if you're not, then
you likely have no meaningful sort order at all.
-- >8 --
Subject: [PATCH] mailsplit: sort maildir filenames more cleverly
A maildir does not technically record the order in which
items were placed into it. That means that when applying a
patch series from a maildir, we may get the patches in the
wrong order. We try to work around this by sorting the
filenames. Unfortunately, this may or may not work depending
on the naming scheme used by the writer of the maildir.
For instance, mutt will write:
${epoch_seconds}.${pid}_${seq}.${host}
where we have:
- epoch_seconds: timestamp at which entry was written
- pid: PID of writing process
- seq: a sequence number to ensure uniqueness of filenames
- host: hostname
None of the numbers are zero-padded. Therefore, when we sort
the names as byte strings, entries that cross a digit
boundary (e.g., 10) will sort out of order. In the case of
timestamps, it almost never matters (because we do not cross
a digit boundary in the epoch time very often these days).
But for the sequence number, a 10-patch series would be
ordered as 1, 10, 2, 3, etc.
To fix this, we can use a custom sort comparison function
which traverses each string, comparing chunks of digits
numerically, and otherwise doing a byte-for-byte comparison.
That would sort:
123.456_1.bar
123.456_2.bar
...
123.456_10.bar
according to the sequence number. Since maildir does not
define a filename format, this is really just a heuristic.
But it happens to work for mutt, and there is a reasonable
chance that it will work for other writers, too (at least as
well as a straight sort).
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/mailsplit.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/builtin/mailsplit.c b/builtin/mailsplit.c
index 2d43278..772c668 100644
--- a/builtin/mailsplit.c
+++ b/builtin/mailsplit.c
@@ -130,6 +130,26 @@ static int populate_maildir_list(struct string_list *list, const char *path)
return 0;
}
+static int maildir_filename_cmp(const char *a, const char *b)
+{
+ while (1) {
+ if (isdigit(*a) && isdigit(*b)) {
+ long int na, nb;
+ na = strtol(a, (char **)&a, 10);
+ nb = strtol(b, (char **)&b, 10);
+ if (na != nb)
+ return na - nb;
+ /* strtol advanced our pointers */
+ }
+ else {
+ if (*a != *b)
+ return *a - *b;
+ a++;
+ b++;
+ }
+ }
+}
+
static int split_maildir(const char *maildir, const char *dir,
int nr_prec, int skip)
{
@@ -139,6 +159,8 @@ static int split_maildir(const char *maildir, const char *dir,
int i;
struct string_list list = STRING_LIST_INIT_DUP;
+ list.cmp = maildir_filename_cmp;
+
if (populate_maildir_list(&list, maildir) < 0)
goto out;
--
1.8.1.39.gbb3bf60
^ permalink raw reply related
* Re: suggestion for a simple addition: git update-ref --ff-only
From: Junio C Hamano @ 2013-03-01 23:33 UTC (permalink / raw)
To: David Madore; +Cc: git
In-Reply-To: <20130301231859.GA334@achernar.madore.org>
David Madore <david+news@madore.org> writes:
> Hi list,
>
> I'd like to suggest a very simple, but IMHO quite useful, additional
> option to git-update-ref: an option --ff-only which would cause the
> command to refuse unless the current ref is an ancestor of the new
> one.
Mild NAK.
What you want may be "git push . new_commit:refs/heads/foo", by the
way.
The "update-ref" plumbing does not want any such frill.
^ permalink raw reply
* suggestion for a simple addition: git update-ref --ff-only
From: David Madore @ 2013-03-01 23:18 UTC (permalink / raw)
To: git
Hi list,
I'd like to suggest a very simple, but IMHO quite useful, additional
option to git-update-ref: an option --ff-only which would cause the
command to refuse unless the current ref is an ancestor of the new
one.
The reason I think it would be useful: I occasionally wish to perform
a trivial (i.e., fast-forward) merge of some branch into another
(e.g., after a git-fetch) without checking it out. Now git-update-ref
is perfect for that, but there is always the possibility of getting
something wrong (which one would not have with git merge --ff-only,
but the latter requires checking out the branch), and this option
would avoid tedious verifications.
Happy hacking,
--
David A. Madore
( http://www.madore.org/~david/ )
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Junio C Hamano @ 2013-03-01 23:24 UTC (permalink / raw)
To: Jeff King; +Cc: William Giokas, git
In-Reply-To: <20130301230508.GC862@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote:
> ...
>> The maildir spec explicitly says that readers should not make
>> assumptions about the content of the filenames. Mutt happens to write
>> them as:
>>
>> ${epoch_seconds}.${pid}_${seq}.${host}
>>
>> so in practice, sorting them kind of works. Except that ...
>> << it does not work >> ...
> That ordering is not necessarily useful.
> ...
> So it is somewhat against the maildir spec, but I think in practice it
> would help.
I do not think it would help, unless these epoch_seconds are the
sender timestamps. And the number of digits in epoch-seconds for
recent messages would be the same, so ordering textually would be
sufficient if ordering by timestamp were.
^ permalink raw reply
* Re: two-way merge corner case bug
From: Jeff King @ 2013-03-01 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vppzien3i.fsf@alter.siamese.dyndns.org>
On Fri, Mar 01, 2013 at 03:06:57PM -0800, Junio C Hamano wrote:
> > I can believe it. So do we want to do that fix, then? Did you want to
> > roll up the two halves of it with a test and write a commit message? I
> > feel like you could write a much more coherent one than I could on this
> > subject.
>
> I actually was wondering if we can remove that sole uses of two-way
> merge with --reset -u from "git am" and replace them with something
> else. But we do want to keep local change that existed before "am"
> started, so we cannot avoid use of two-way merge, I guess...
Yeah, I think that is a case we definitely want to keep, as it means any
intermediate work done by the user in applying the patch is not lost.
-Peff
^ permalink raw reply
* Re: two-way merge corner case bug
From: Junio C Hamano @ 2013-03-01 23:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130301223612.GA862@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote:
>>
>> Nobody seems to use that combination, either from scripts or from C
>> (i.e. when opts.update==1 and opts.merge==1, opts.reset is not set)
>> with a twoway merge, other than "git am --abort/--skip".
>
> I can believe it. So do we want to do that fix, then? Did you want to
> roll up the two halves of it with a test and write a commit message? I
> feel like you could write a much more coherent one than I could on this
> subject.
I actually was wondering if we can remove that sole uses of two-way
merge with --reset -u from "git am" and replace them with something
else. But we do want to keep local change that existed before "am"
started, so we cannot avoid use of two-way merge, I guess...
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Jeff King @ 2013-03-01 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: William Giokas, git
In-Reply-To: <20130301225231.GB862@sigill.intra.peff.net>
On Fri, Mar 01, 2013 at 05:52:31PM -0500, Jeff King wrote:
> > Note to bystanders. This is coming from populate_maildir_list() in
> > builtin/mailsplit.c; the function claims to know what "maildir"
> > should look like, so it should be enforcing the ordering as
> > necessary by sorting the list, _if_ the implicit ordering given by
> > string_list_insert() is insufficient.
> [...]
>
> I think it is a property of the maildir format that it does not
> technically define the message order. The order of items you get from
> readdir is filesystem specific and not necessarily defined (and that is
> what we use now). On my ext4 system, I do not even get them in backwards
> order; it is jumbled.
Hmph, sorry, I mistook string_list_insert for string_list_append. So we
do actually sort them by filename, not just random readdir order. But
due to this:
> The maildir spec explicitly says that readers should not make
> assumptions about the content of the filenames. Mutt happens to write
> them as:
>
> ${epoch_seconds}.${pid}_${seq}.${host}
>
> so in practice, sorting them kind of works. Except that a series written
> out at once will all have the same timestamp and pid, and because ${seq}
> is not zero-padded, you have to actually parse up to there and do a
> numeric instead of byte-wise comparison. So we can add a mutt-specific
> hack, but that's the best we can do. Other maildir writers (including
> future versions of mutt) will not necessarily do the same thing.
That ordering is not necessarily useful.
So one strategy could be to try harder to sort numeric elements
numerically. That is, to treat:
1234.5678_90.foo
as the list
{1234, '.', 5678, '_', 90, "foo"}
for the purposes of sorting (even though we do not necessarily know what
each piece means). That works for mutt and similar schemes (dovecot, for
example, does something like "M${seq}P${pid}"), but some systems may put
random bytes in the middle (the point of it is to create a unique name).
So it is somewhat against the maildir spec, but I think in practice it
would help.
-Peff
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Jeff King @ 2013-03-01 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: William Giokas, git
In-Reply-To: <7vwqtqeox7.fsf@alter.siamese.dyndns.org>
On Fri, Mar 01, 2013 at 02:27:32PM -0800, Junio C Hamano wrote:
> > I've been using git for a while and this is the first time I've had to
> > use `git am` and I've got a 16 patch patchset that I'm looking to apply.
> > The files were copied to a separate maildir by mutt to keep things
> > clean, and then I ran `git am -i /path/to/maildir/` expecting things to
> > start from the patch with the subject
> >
> > [PATCH 01/16] refactor common code in query_search/sync_search
> >
> > But instead, it starts with the 16/16 patch and works backwards, which,
> > obviously, breaks the application process as the patches depend on each
>
> Note to bystanders. This is coming from populate_maildir_list() in
> builtin/mailsplit.c; the function claims to know what "maildir"
> should look like, so it should be enforcing the ordering as
> necessary by sorting the list, _if_ the implicit ordering given by
> string_list_insert() is insufficient.
>
> It also is likely that it is a user error to expect that patch
> e-mails are received and stored in the maildir in the order they
> were sent, or it could be "mutt" copying the mails in the order the
> messages were originally received, or something silly like that.
I think it is a property of the maildir format that it does not
technically define the message order. The order of items you get from
readdir is filesystem specific and not necessarily defined (and that is
what we use now). On my ext4 system, I do not even get them in backwards
order; it is jumbled.
We could sort based on the mtime of the file, but in some cases that
won't have sufficient resolution (e.g., with one second resolution,
they'll all probably have the same timestamp).
The maildir spec explicitly says that readers should not make
assumptions about the content of the filenames. Mutt happens to write
them as:
${epoch_seconds}.${pid}_${seq}.${host}
so in practice, sorting them kind of works. Except that a series written
out at once will all have the same timestamp and pid, and because ${seq}
is not zero-padded, you have to actually parse up to there and do a
numeric instead of byte-wise comparison. So we can add a mutt-specific
hack, but that's the best we can do. Other maildir writers (including
future versions of mutt) will not necessarily do the same thing.
I think maildir's philosophy is that ordering is not important, and the
contents of the messages themselves should define the order in which a
MUA presents them, anyway. It would make sense to me if we actually
parsed the '[PATCH n/m]' bit from the subject of each and sorted based
on that. That is blurring the line between git-mailsplit and
git-mailinfo, in that mailsplit would have to start parsing the files.
We could also sort based on the rfc822 "Date" header, but I don't think
that is a good idea. It represents the author timestamp, so patches
moved via "rebase -i" will have out-of-sequence dates with respect to
the actual history graph. You can encounter this if you "format-patch
--stdout" a series into a single mbox and load it into a MUA that sorts
by date (like mutt). The patches appear jumbled until you switch to
"unsorted" or "sort by subject".
-Peff
^ permalink raw reply
* Re: two-way merge corner case bug
From: Jeff King @ 2013-03-01 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9qngisg.fsf@alter.siamese.dyndns.org>
On Fri, Mar 01, 2013 at 08:57:03AM -0800, Junio C Hamano wrote:
> An initial checkout is *supposed* to happen in an empty working
> tree, so if we code it not to overwrite an existing path in the
> working tree, the user cannot lose possibly precious contents with
> an mistaken initial checkout (they will instead appear as modified
> relative to the index), while in the normal case we will write out
> the contents from the HEAD through the index. We could attempt "we
> do not have to if the user behaves, but with this we could help
> misbehaving users" if we used twoway merge for an initial checkout.
That matches my thinking. It is probably not worth touching, though,
since it is not causing any problems. I just found it curious that the
exact same (and only, as far as I can see) exception we make for
initial_checkout is the same thing we have to tweak here.
> Having said that, I notice that in the normal codepath (e.g. "git
> clone" without the "--no-checkout" option) we no longer use twoway
> merge for the initial checkout. Back when "git clone" was a
> scripted Porcelain, I think we used to do a twoway read-tree. It
> may be that we broke it when "clone" was rewritten in C, but the
> breakage is to the "we do not have to..." thing, so it may not be a
> big deal.
The one-way merge that we use now in clone makes a lot of sense to me.
We do not have a "previous state" we were based on.
> The only case that matters in today's code is "git checkout"
> (without any option or argument) immediately after "git clone -n", I
> think. The special casing for this initial checkout in twoway merge
> is needed because we go from HEAD to HEAD in that case, and we do
> not want to keep the artificial local removals from the index; we
> start from not even having the $GIT_INDEX_FILE, so without the
> special case all paths appear to have been "rm --cached", which is
> usually not what the user would want to see ;-)
Right. I just wondered if such a checkout should instead be a "reset",
in which case it would fall under the proposed patch. But "git checkout"
never does a twoway_merge with o->reset; instead, it uses a one-way
merge.
Anyway, that is all tangential to the bug at hand.
> > ... My worry would be that somebody is
> > using "--reset" but expecting the removal to be carried through
> > (technically, "--reset" is documented as "-m but discard unmerged
> > entries", but we are not really treating it that way here).
>
> I've checked all in-tree uses of "read-tree --reset -u".
>
> Nobody seems to use that combination, either from scripts or from C
> (i.e. when opts.update==1 and opts.merge==1, opts.reset is not set)
> with a twoway merge, other than "git am --abort/--skip".
I can believe it. So do we want to do that fix, then? Did you want to
roll up the two halves of it with a test and write a commit message? I
feel like you could write a much more coherent one than I could on this
subject.
-Peff
^ permalink raw reply
* Re: [bug report] git-am applying maildir patches in reverse
From: Junio C Hamano @ 2013-03-01 22:27 UTC (permalink / raw)
To: William Giokas; +Cc: git
In-Reply-To: <20130301222018.GA839@WST420>
William Giokas <1007380@gmail.com> writes:
> All,
>
> I've been using git for a while and this is the first time I've had to
> use `git am` and I've got a 16 patch patchset that I'm looking to apply.
> The files were copied to a separate maildir by mutt to keep things
> clean, and then I ran `git am -i /path/to/maildir/` expecting things to
> start from the patch with the subject
>
> [PATCH 01/16] refactor common code in query_search/sync_search
>
> But instead, it starts with the 16/16 patch and works backwards, which,
> obviously, breaks the application process as the patches depend on each
> other. I looked in the maildir directory just to see if the file names
> were backwards, and that's not the issue. I talked to `gitster` on IRC
> and he said to send in a bug report on this issue here. The patchset I'm
> trying to apply can be found here[0].
>
> Process to reproduce:
> * find a multi-patch set with interdependent patches
> * run `git am` on the maildir containing these patches
>
> Expected result:
> * Apply patches in [01..N] order
>
> Actual result:
> * Patches applied in [N N-1..01] order
Note to bystanders. This is coming from populate_maildir_list() in
builtin/mailsplit.c; the function claims to know what "maildir"
should look like, so it should be enforcing the ordering as
necessary by sorting the list, _if_ the implicit ordering given by
string_list_insert() is insufficient.
It also is likely that it is a user error to expect that patch
e-mails are received and stored in the maildir in the order they
were sent, or it could be "mutt" copying the mails in the order the
messages were originally received, or something silly like that.
>
> [0]: https://mailman.archlinux.org/pipermail/pacman-dev/2013-March/016541.html
>
> Thank you,
^ permalink raw reply
* [bug report] git-am applying maildir patches in reverse
From: William Giokas @ 2013-03-01 22:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
All,
I've been using git for a while and this is the first time I've had to
use `git am` and I've got a 16 patch patchset that I'm looking to apply.
The files were copied to a separate maildir by mutt to keep things
clean, and then I ran `git am -i /path/to/maildir/` expecting things to
start from the patch with the subject
[PATCH 01/16] refactor common code in query_search/sync_search
But instead, it starts with the 16/16 patch and works backwards, which,
obviously, breaks the application process as the patches depend on each
other. I looked in the maildir directory just to see if the file names
were backwards, and that's not the issue. I talked to `gitster` on IRC
and he said to send in a bug report on this issue here. The patchset I'm
trying to apply can be found here[0].
Process to reproduce:
* find a multi-patch set with interdependent patches
* run `git am` on the maildir containing these patches
Expected result:
* Apply patches in [01..N] order
Actual result:
* Patches applied in [N N-1..01] order
[0]: https://mailman.archlinux.org/pipermail/pacman-dev/2013-March/016541.html
Thank you,
--
William Giokas | KaiSforza
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1.5
From: Junio C Hamano @ 2013-03-01 22:16 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.1.5 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
3349a15de7c5501715bda9b68301d0406272f8e0 git-1.8.1.5.tar.gz
84d832fc70a053e97ce336c4a0af0371461e469f git-htmldocs-1.8.1.5.tar.gz
7f211a2f8fe36180373a20b32eb930018883bfd1 git-manpages-1.8.1.5.tar.gz
Also the following public repositories all have a copy of the v1.8.1.5
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git 1.8.1.5 Release Notes
=========================
Fixes since v1.8.1.4
--------------------
* Given a string with a multi-byte character that begins with '-' on
the command line where an option is expected, the option parser
used just one byte of the unknown letter when reporting an error.
* In v1.8.1, the attribute parser was tightened too restrictive to
error out upon seeing an entry that begins with an ! (exclamation),
which may confuse users to expect a "negative match", which does
not exist. This has been demoted to a warning; such an entry is
still ignored.
* "git apply --summary" has been taught to make sure the similarity
value shown in its output is sensible, even when the input had a
bogus value.
* "git clean" showed what it was going to do, but sometimes ended
up finding that it was not allowed to do so, which resulted in a
confusing output (e.g. after saying that it will remove an
untracked directory, it found an embedded git repository there
which it is not allowed to remove). It now performs the actions
and then reports the outcome more faithfully.
* "git clone" used to allow --bare and --separate-git-dir=$there
options at the same time, which was nonsensical.
* "git cvsimport" mishandled timestamps at DST boundary.
* We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
* The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
* "git help remote-helpers" failed to find the documentation.
* "gitweb" pages served over HTTPS, when configured to show picon or
gravatar, referred to these external resources to be fetched via
HTTP, resulting in mixed contents warning in browsers.
Also contains various documentation fixes.
----------------------------------------------------------------
Changes since v1.8.1.4 are as follows:
Andrej E Baranov (1):
gitweb: refer to picon/gravatar images over the same scheme
Andrew Wong (1):
Documentation/githooks: Fix linkgit
Asheesh Laroia (1):
git-mergetool: print filename when it contains %
Ben Walton (3):
Move Git::SVN::get_tz to Git::get_tz_offset
perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases
cvsimport: format commit timestamp ourselves without using strftime
Brad King (1):
Documentation/submodule: Add --force to update synopsis
David Aguilar (3):
mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
difftool--helper: fix printf usage
p4merge: fix printf usage
Erik Faye-Lund (1):
parse-options: report uncorrupted multi-byte options
Greg Price (1):
Documentation: "advice" is uncountable
Jeff King (2):
http_request: reset "type" strbuf before adding
Makefile: avoid infinite loop on configure.ac change
Jiang Xin (1):
Add utf8_fprintf helper that returns correct number of columns
John Keeping (3):
Rename {git- => git}remote-helpers.txt
builtin/apply: tighten (dis)similarity index parsing
t4038: add tests for "diff --cc --raw <trees>"
Junio C Hamano (7):
doc: mention tracking for pull.default
combine-diff: lift 32-way limit of combined diff
t5551: fix expected error output
user-manual: typofix (ofthe->of the)
Prepare for 1.8.1.5
Update draft release notes to 1.8.1.5
Git 1.8.1.5
Matthieu Moy (1):
git.txt: update description of the configuration mechanism
Michael J Gruber (1):
git-bisect.txt: clarify that reset quits bisect
Nguyễn Thái Ngọc Duy (1):
clone: forbid --bare --separate-git-dir <dir>
Shawn O. Pearce (1):
Verify Content-Type from smart HTTP servers
Thomas Rast (1):
Make !pattern in .gitattributes non-fatal
W. Trevor King (4):
user-manual: Update for receive.denyCurrentBranch=refuse
user-manual: Reorganize the reroll sections, adding 'git rebase -i'
user-manual: Use request-pull to generate "please pull" text
user-manual: Flesh out uncommitted changes and submodule updates
Zoltan Klinger (1):
git-clean: Display more accurate delete messages
^ permalink raw reply
* Re: Subtree in Git
From: Paul Campbell @ 2013-03-01 22:05 UTC (permalink / raw)
To: Kindjal; +Cc: git, David Michael Barr
In-Reply-To: <loom.20130301T032627-983@post.gmane.org>
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal <kindjal@gmail.com> wrote:
> David Michael Barr <b <at> rr-dav.id.au> writes:
>
>> From a quick survey, it appears there are no more than 55 patches
>> squashed into the submitted patch.
>> As I have an interest in git-subtree for maintaining the out-of-tree
>> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
>> to make some sense of the organic growth that happened on GitHub.
>> It doesn't appear that anyone else is willing to do this, so I doubt
>> there will be any duplication of effort.
>>
>
> What is the status of the work on git-subtree described in this thread?
> It looks like it's stalled.
>
I hadn't been aware of that patch. Reading the thread David Michael
Barr was going to try picking the patch apart into sensible chunks.
My own patches, some of which I've submitted to the list, appear to be
tackling a couple of the same things (e.g. storing subtree metadata in
an ini file). Mine can be found here
(https://github.com/kemitix/git/commits/subtree-usability), including
some I've not submitted yet.
If this work is still needing done I'd like to volunteer.
--
Paul [W] Campbell
^ permalink raw reply
* Re: [PATCH] Make !pattern in .gitattributes non-fatal
From: Junio C Hamano @ 2013-03-01 21:53 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <87mwumx36m.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>>> Before 82dce99 (attr: more matching optimizations from .gitignore,
>>> 2012-10-15), .gitattributes did not have any special treatment of a
>>> leading '!'. The docs, however, always said
>>>
>>> The rules how the pattern matches paths are the same as in
>>> `.gitignore` files; see linkgit:gitignore[5].
>>>
>>> By those rules, leading '!' means pattern negation. So 82dce99
>>> correctly determined that this kind of line makes no sense and should
>>> be disallowed.
>>>
>>> However, users who actually had a rule for files starting with a '!'
>>> are in a bad position: before 82dce99 '!' matched that literal
>>> character, so it is conceivable that users have .gitattributes with
>>> such lines in them. After 82dce99 the unescaped version was
>>> disallowed in such a way that git outright refuses to run(!) most
>>> commands in the presence of such a .gitattributes. It therefore
>>> becomes very hard to fix, let alone work with, such repositories.
>>
>> Fixing the working tree is easy, but when we read from a history
>> that already records such an entry in an attribute file, it would
>> become somewhat cumbersome. I wouldn't use "very hard to fix" to
>> describe such a case.
>
> Well, I'm sorry if I hurt any feelings there, but...
>
> ~/tmp/badattr(master)$ git show bad:.gitattributes
> !bad text
> ~/tmp/badattr(master)$ ~/g/git-checkout bad # a git without my patch
> fatal: Negative patterns are forbidden in git attributes
> Use '\!' for literal leading exclamation.
> ~/tmp/badattr(master)$ git status
> # On branch master
> nothing to commit (use -u to show untracked files)
>
> Notice how it remains on master. I suppose with enough knowledge of the
> internals I could manage,...
That would have been nicer to have in the log message.
In any case, 1.8.1.5 will go out with this fix (this is v1.8.1
regression IIUC) this afternoon. Thanks for a fix.
^ permalink raw reply
* RE: [PATCH] In inproperly merges, the ranges contains additional character "*"
From: Jan Pešta @ 2013-03-01 21:37 UTC (permalink / raw)
To: 'Junio C Hamano'; +Cc: git, 'Matthieu Moy'
In-Reply-To: <7v1ubzgg4e.fsf@alter.siamese.dyndns.org>
Hi Junio,
You have right. But I think if there is a "*" sign, it should be skiped, instead of failing on comparing string with a number.
I will prepare another patch.
Regards,
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
E-mail: jan.pesta@certicon.cz
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Junio C Hamano
Sent: Friday, March 01, 2013 6:55 PM
To: Jan Pešta
Cc: git@vger.kernel.org; 'Matthieu Moy'
Subject: Re: [PATCH] In inproperly merges, the ranges contains additional character "*"
Jan Pešta <jan.pesta@certicon.cz> writes:
> In inproperly merges, the ranges contains additional character "*".
Thanks, but -ECANNOTPARSE. What are "inproperly merges"?
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
> The range r30430:30435 that was added to 1.5.x in this merge has a '*'
> suffix for 1.5.x\www.
> This '*' is the marker for a non-inheritable mergeinfo range.
> The '*' means that only the path on which the mergeinfo is explicitly set
> has had this range merged into it.
If I am reading the above correctly, blindly removing '*' from the
range will record a wrong merge in the result, because on the SVN
side only the history of part of the tree is merged but we represent
the result as a full merge (and Git only records full merge of
histories), no?
My gut feeling tells me that failing the import, saying "We cannot
represent this history", might be a more honest and safe thing to
do.
> Signed-off-by: Jan Pesta <jan.pesta@certicon.cz>
> ---
> perl/Git/SVN.pm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
> index 0ebc68a..6bd18e9 100644
> --- a/perl/Git/SVN.pm
> +++ b/perl/Git/SVN.pm
> @@ -1493,6 +1493,7 @@ sub lookup_svn_merge {
> my @merged_commit_ranges;
> # find the tip
> for my $range ( @ranges ) {
> + $range =~ s/[*]$//;
> my ($bottom, $top) = split "-", $range;
> $top ||= $bottom;
> my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
^ permalink raw reply
* Re: problem switching branches
From: J.V. @ 2013-03-01 20:52 UTC (permalink / raw)
Cc: git@vger.kernel.org
In-Reply-To: <20130227051740.GB10976@sigill.intra.peff.net>
On 2/26/2013 10:17 PM, Jeff King wrote:
> On Tue, Feb 26, 2013 at 04:08:55PM -0700, J.V. wrote:
>
>> I was on my master branch, I then checked out a branch (
>> origin/somebranch ), made no updates
>> but did a few git pulls on the branch over about a week; then made a
>> small change to only a single file & committed & pushed.
>>
>> Now am trying to go back to my master branch and get:
>>
>> error: The following untracked working tree files would be
>> overwritten by checkout:
>> lib/derbyclient.jar
>> Please move or remove them before you can switch branches.
>> Aborting
>>
>>
>> I did not put that jar file there (I edited a single config file),
>> how do I now get back to my master branch?
> Not knowing anything about your project, it's impossible to say for
> sure, but this often happens with something like:
>
> 1. lib/derbyclient.jar used to be generated by your project's build
> procedure
This jar was put on the master branch last year; It does not exist in
the branch that I am now on where I get the error message (I am on a
branch that was created for a previous release).
>
> 2. You did a build of your project, generating the file in your
> working tree.
This jar is downloaded from the web and put there; we did not generate.
>
> 3. Meanwhile, somebody upstream added and commited lib/derbyclient.jar
> directly in the repository. This might have been intentional (it
> used to be a generated file, but now is included as source), or it
> may have been an accident (mistaken use of `git add`).
It was committed intentionally, last year, but does not exist in the
branch that I am now on, but it is there.
>
> 4. You try to switch to the master branch with the new commits from
> (3). Git sees that the copy of the file in your working tree would
> be overwritten and lost (since it was never committed by you), so
> aborts.
>
> If you are sure that the file in the working tree does not contain
> anything interesting, you can use "git checkout -f master" to force the
> overwrite.
I will try this.
>
>> I do not want to muck up the branch that I am now on by deleting anything.
>> Any ideas how this happened?
> You won't hurt the branch you are on; you will just lose the contents in
> the untracked working tree file. That's probably fine if it is a
> generated file, as in the scenario I described above. We know that the
> file is not included in the branch you are on (otherwise, it would not
> be listed as untracked). And even if it were, you would only impact the
> branch by committing the changes, not by changing the working tree.
>
>> Obviously someone put derbyclient.jar there, not sure, but it is
>> supposed to be there so do not want to remove as advised.
> It won't be removed; it will be overwritten with the version of the file
> that is on "master". Which is probably what you want; you may want to
> look at `git log master -- lib/derbyclient.jar` to see why it was added.
>
> -Peff
^ 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