* Re: Repo corrupted somehow?
From: Daniel Barkalow @ 2008-11-05 5:56 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811042127id69b61fqbd9d001b8bc17a6a@mail.gmail.com>
On Tue, 4 Nov 2008, Andrew Arnott wrote:
> It was the CRLF conversion. When I played around with
> git config --global core.autocrlf true/false
> I got the problem to eventually go away.
>
> Thanks for all your responses.
It's still worth debugging further, because git should know that it wrote
the files differently and not see that as changes. It's not too helpful to
have autocrlf if it causes this problem.
Are you using something (like .gitattributes) to mark files as text or as
non-text? Is this under Cygwin? It might be fixed in a newer version,
also.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Andrew Arnott @ 2008-11-05 5:40 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <216e54900811042127id69b61fqbd9d001b8bc17a6a@mail.gmail.com>
It was the CRLF conversion. When I played around with
git config --global core.autocrlf true/false
I got the problem to eventually go away.
Thanks for all your responses.
>
> On Tue, Nov 4, 2008 at 8:21 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>>
>> On Mon, 3 Nov 2008, Andrew Arnott wrote:
>>
>> > I was just git commit'ing, and then I was doing a git rebase to squash
>> > several commits into one when the rebase failed. I then did a
>> > git checkout -f master
>> > git reset --hard
>> > but no matter what I do, git thinks that several files have changed.
>> > The diff shows all the lines in these several files removed and then
>> > added, yet without any changes made to them.
>>
>> That sounds like some failure of CRLF conversion, like it's converting all
>> of the line endings somehow when writing to the working tree and then not
>> expecting them to be different. Do you have some sort of interesting
>> configuration for those? I wonder if you've got a .gitattributes that
>> matches the names that git uses for the files, but are on a
>> case-insensitive filesystem which lists those files in a way where their
>> names don't match (or vice versa).
>>
>> -Daniel
>> *This .sig left intentionally blank*
>
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Daniel Barkalow @ 2008-11-05 4:21 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811032309s51c8cb1fr64054ff18c450b1d@mail.gmail.com>
On Mon, 3 Nov 2008, Andrew Arnott wrote:
> I was just git commit'ing, and then I was doing a git rebase to squash
> several commits into one when the rebase failed. I then did a
> git checkout -f master
> git reset --hard
> but no matter what I do, git thinks that several files have changed.
> The diff shows all the lines in these several files removed and then
> added, yet without any changes made to them.
That sounds like some failure of CRLF conversion, like it's converting all
of the line endings somehow when writing to the working tree and then not
expecting them to be different. Do you have some sort of interesting
configuration for those? I wonder if you've got a .gitattributes that
matches the names that git uses for the files, but are on a
case-insensitive filesystem which lists those files in a way where their
names don't match (or vice versa).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Geoff Russell @ 2008-11-05 3:54 UTC (permalink / raw)
To: Bob Hiestand; +Cc: git, Johannes Schindelin
In-Reply-To: <cc29171c0811041618jfbcb293l42a19805f06803a0@mail.gmail.com>
On Wed, Nov 5, 2008 at 10:48 AM, Bob Hiestand <bob.hiestand@gmail.com> wrote:
> On Tue, Nov 4, 2008 at 4:49 PM, Geoff Russell
> <geoffrey.russell@gmail.com> wrote:
>> Apologies to Johannes and Bob who have tried to help
>> but I'm still having difficulties, here is my current non-working script:
>>
>> ------------------------------------------------------------------
>> #!/bin/sh
>> DIR=/tmp/gitdemo
>> # for testing just arbitrarily
>> # select the 15th most recent commit as our new origin
>> NEWORIGIN=$(git rev-list master@{15} | head -1)
>> echo $NEWORIGIN
>> # checkout earlist point we are interested in
>> # we want to drop any history before this point
>> git checkout $NEWORIGIN
>> # now make a new directory, initialise with new origin
>> # and apply all commits after that point
>> mkdir $DIR && (cd $DIR ; git init) && \
>> rsync -aHv --exclude=.git ./ $DIR && \
>> (cd $DIR ; git add . ; git commit -m "starting point" </dev/null ) && \
>> git fast-export $NEWORIGIN..master | (cd $DIR ; git fast-import )
>>
>> ----------------- end of script
>>
>> The fast-import gives me a message I don't understand and doesn't
>> do the import.
>
> If I understood your requirement (I know nothing about fast-export),
> it would look like this:
>
> #!/bin/sh
> DIR=/tmp/gitdemo
> ORIGDIR=$PWD
> git checkout -b shorthistory
> NEWORIGIN=$(git rev-list --since='5 months ago' --reverse HEAD| head -1)
> echo $NEWORIGIN
> git filter-branch --parent-filter '
> test $GIT_COMMIT = '$NEWORIGIN' &&
> echo || cat' \
> --tag-name-filter cat $NEWORIGIN^..
> mkdir $DIR
> cd $DIR
> git init
> git fetch $ORIGDIR shorthistory:master
Thanks Bob but when I ran your version (using master@{15} instead of
--since =...) it
effectively dropped the recent history, not the old history. Imagine a sequence
of 30 commits, no branches. I want to keep, for example, 15 through
30 and dump 1
to 15. So I need to have the working directory as at commit 15 and
then all the changes
to bring it up to 30.
... 11--12--13--14--15 ... 28--29--30
... Dump 1 to 15 keep 15 to 30.
Your script kept 1 to 15 and dumped the rest.
Cheers,
Geoff.
>
>
> Thank you,
>
> bob
>
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Jeff King @ 2008-11-05 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vprlbnj1t.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 04, 2008 at 03:54:54PM -0800, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > Automatically turn --compose on when there is more than one patch, and
> > that the output is a tty.
>
> I do not think this is a good idea. I suspect I am not the only person
> who uses "format-patch --cover-letter", edit the files to review and
> prepare, and runs send-email to fire them off.
Maybe a config option to turn this behavior on? It seems specific to
different workflows (i.e., whether or not you are using "git send-email
$REVS" or using format-patch first).
-Peff
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Jeff King @ 2008-11-05 3:29 UTC (permalink / raw)
To: Andrew Arnott; +Cc: git
In-Reply-To: <216e54900811040712k51db6fbfu44c59d9f90f1eabd@mail.gmail.com>
On Tue, Nov 04, 2008 at 07:12:40AM -0800, Andrew Arnott wrote:
> Nah, that wasn't a false alarm after all. It's happening again, only
> this time for dozens of files, and
> git rebase --abort
> git reset --hard
>
> is not helping.
This is certainly unusual. Can you provide a tarball of your repo
(including .git and working tree)? I don't know that a clone will be
sufficient if there is something funny going on in your local git index.
-Peff
^ permalink raw reply
* Re: Intensive rename detection
From: Jeff King @ 2008-11-05 3:22 UTC (permalink / raw)
To: Andrew Arnott; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <216e54900811032236l5ae4bde5v16ab6519962e428f@mail.gmail.com>
On Mon, Nov 03, 2008 at 10:36:42PM -0800, Andrew Arnott wrote:
> Yes, on git status. I'm afraid I don't know how to look up the
> reference you gave.
Sorry, gmane is back up, so the link is:
http://article.gmane.org/gmane.comp.version-control.git/99147
With that patch, and this one on top, "git status" should respect your
rename limits (though I haven't tested it).
---
diff --git a/wt-status.c b/wt-status.c
index c3a9cab..0b92ac3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -214,7 +214,6 @@ static void wt_status_print_updated(struct wt_status *s)
rev.diffopt.format_callback = wt_status_print_updated_cb;
rev.diffopt.format_callback_data = s;
rev.diffopt.detect_rename = 1;
- rev.diffopt.rename_limit = 200;
rev.diffopt.break_opt = 0;
run_diff_index(&rev, 1);
}
-Peff
^ permalink raw reply related
* Re: CRLF support bugs (was: Re: .gitattributes glob matchingbroken)
From: Jeff King @ 2008-11-05 3:07 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: Hannu Koivisto, git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F79430296676E@emailmn.mqsoftware.com>
On Tue, Nov 04, 2008 at 06:37:27AM -0600, Kelly F. Hickel wrote:
> From my point of view, the factoid that a particular file should be
> subjected to having its line endings munged is a _project_ decision.
> Whether or not to munge them on any given platform is a _local_
> decision.
Now that you spell it out, I am reminded that that is the argument I
remember having seen in past discussions. And of course, that argues for
.gitattributes being carried by the project, but the core.autocrlf
_config_ being a local decision.
Which, perhaps not coincidentally, is how it is currently implemented. :)
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jeff King @ 2008-11-05 3:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sam Vilain, Dmitry Potapov, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <7vr65rqnoj.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 04, 2008 at 11:46:36AM -0800, Junio C Hamano wrote:
> These days, people who would want the maching behaviour can explicitly ask
> for it, so there is one less reason to resist changing the default
> (i.e. earlier explicitly askinf for "matching" was impossible, but now we
> can). The remaining reason of resistance is pure inertia (i.e. not
> changing the behaviour of the command only because you upgraded your git),
> and the only way to address it is to start issuing the warning when "git
> push" or "git push $there" is used and the matching behaviour was chosen
> without configuration (i.e. no "remote.<there>.push = :"), and keep it
> that way for two release cycles, and finally change the default.
Hmm. It really seems to me that there are two desires for push behavior,
based on particular workflows. I.e., some people seem to want the
matching behavior by default, and others want to push the current
branch.
And we already can control that via configuration of the refspec. So any
argument that "git push should do the same thing even on somebody else's
setup" is already wrong. But I do think Junio has a good point, which is
that there is going to be confusion if upgrading git suddenly causes
"git push" to do something else.
So why not take one step back in the behavior change? We can set up the
"push just this branch" refspec during clone, which will leave existing
repositories untouched. And to make things even gentler, we can start
with opt-in to the clone feature, notify users via the release notes
(which, as we have established, EVERYONE reads), and then decide if and
when to switch the option on by default.
So something like a "remote.push" config option, the value of which gets
added to newly created remotes (including those created on clone). It
would default to ":", but you could easily set "git config remote.push
HEAD" to get the other behavior.
No, this doesn't get rid of the eventual need to choose whether to
switch the default. But I think it eases us into it a little more. And I
think such an option is a lot more generally applicable than a "default
push to matching versus HEAD" option.
-Peff
^ permalink raw reply
* Re: [PATCH v2] push: fix local refs update if already up-to-date
From: Jeff King @ 2008-11-05 2:51 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Junio C Hamano, git
In-Reply-To: <20081104205743.GA26788@localhost>
On Tue, Nov 04, 2008 at 09:57:43PM +0100, Clemens Buchacher wrote:
> On Mon, Nov 03, 2008 at 11:26:44PM -0500, Jeff King wrote:
> > Nit: Just reading the test, it is hard to see what is interesting about
> > it (though obviously I can blame it back to your commit :) ). Maybe a
> > more descriptive title like 'push updates uptodate local refs' would
> > make sense.
>
> That is all I changed in this update. Pending an Ack/Nack from Jeff I feel
> that I'm done.
I have to NAK, because the extra written ref is still a problem (see my
other mail). But with that fix (and I hope you both will agree with the
style fixup on removing new_sha1, too), I think it should be good.
-Peff
^ permalink raw reply
* Re: [PATCH] push: fix local refs update if already up-to-date
From: Jeff King @ 2008-11-05 2:49 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano
In-Reply-To: <20081104085630.GA22530@localhost>
On Tue, Nov 04, 2008 at 09:56:30AM +0100, Clemens Buchacher wrote:
> The other status flags are REF_STATUS_REJECT_NODELETE and
> REF_STATUS_REJECT_NONFASTFORWARD. So in these cases the "new sha1" is going
> to be the "old sha1". The default for new_sha1 is the null sha1. So while
> the sha1 we're trying to push may not be more valid than the null sha1, it's
> not less valid either, is it? And it even makes sense if you interpret
> new_sha1 as the sha1 the client attempts to push.
I have to admit I did not exhaustively look at all of the status cases
when I reviewed earlier, and there are fewer than I realized. So I think
your change is reasonable.
However, I would like to make one additional request. Since you are
killing off all usage of new_sha1 initial assignment, I think it makes
sense to just get rid of the variable entirely, so it cannot create
confusion later. Like this (on top of your patch):
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 4c17f48..d139eba 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -435,16 +435,13 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
*/
new_refs = 0;
for (ref = remote_refs; ref; ref = ref->next) {
- const unsigned char *new_sha1;
-
if (!ref->peer_ref) {
if (!args.send_mirror)
continue;
- new_sha1 = null_sha1;
+ hashcpy(ref->new_sha1, null_sha1);
}
else
- new_sha1 = ref->peer_ref->new_sha1;
- hashcpy(ref->new_sha1, new_sha1);
+ hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
ref->deletion = is_null_sha1(ref->new_sha1);
if (ref->deletion && !allow_deleting_refs) {
> > Hmm. I was hoping to see more in update_tracking_ref. With your patch,
> > we end up calling update_ref for _every_ uptodate ref, which results in
> > writing a new unpacked ref file for each one. And that _is_ a
> > performance problem for people with large numbers of refs.
> [...]
> I think update_ref already takes care of that. See this check in
> write_ref_sha1:
>
> if (!lock->force_write && !hashcmp(lock->old_sha1, sha1)) {
> unlock_ref(lock);
> return 0;
> }
Nope. That check is a concurrency safeguard. It checks that when we are
moving the ref from "A" to "B", that the ref still _is_ "A" when we lock
it.
But more importantly, it is easy to demonstrate the problem with your
patch:
mkdir parent &&
(cd parent &&
git init && touch file && git add file && git commit -m one) &&
git clone parent child &&
(cd child &&
echo BEFORE: && ls -l .git/refs/remotes/origin &&
git push &&
echo AFTER: && ls -l .git/refs/remotes/origin)
I get:
BEFORE:
-rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
Everything up-to-date
AFTER:
-rw-r--r-- 1 peff peff 32 2008-11-04 21:43 HEAD
-rw-r--r-- 1 peff peff 41 2008-11-04 21:43 master
Oops. With the patch snippet I posted in my previous message, the
'master' ref is not created by the uptodate push.
> > Though I am not happy that we have to look up the tracking ref for every
> > uptodate ref. I think it shouldn't be a big performance problem with
> > packed refs, though, since they are cached (i.e., we pay only to compare
> > the hashes, not touch the filesystem for each ref).
>
> I don't think we can avoid that, though.
No, you can't avoid it (without totally giving up on your patch's goal,
which I think is a good one). So I think it is worth it, and I was just
being paranoid about hurting performance. Even with packed refs, I think
we do still end up stat()ing for each ref, but we will have to live with
it. I was thinking we might be able to do something clever with values
we had already read for the push, but it is impossible: we have read the
refs we are going to _push_, but we have not looked at the remote
tracking branches, which are what contain the interesting information.
-Peff
^ permalink raw reply related
* Re: git log -S doesn't find some commits
From: Junio C Hamano @ 2008-11-05 1:30 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Johannes Schindelin, git
In-Reply-To: <877i7jrp67.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@norang.ca> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> There seems to be a misconception on what -S<foo> does. It does *NOT*
>> grep for string <foo> in the patch text. It counts number of <foo> in
>> preimage and postimage and decides that the commit is worth showing iff
>> they differ.
>>
>> If you look at, for example (B):
>>
>> http://repo.or.cz/w/org-mode.git?a=commitdiff;h=837c81ce51
>>
>> You can see that in org-publish.el, org-publish-validate-link appears once
>> as removed and once as added, so the total number of the appearance of the
>> symbol in preimage and postimage are the same.
>
> Now I get it :)
>
> Thanks both of you!
By the way, I would not be opposed to a new feature, perhaps triggered
with -G<foo>, that acts as if it is grepping inside the patch text.
The reason behind -S<foo>'s behaviour is because it was designed as a part
ofa "incremetal digging" tool before the current "git-blame" that allows
to track even line-movements.
That is, you could write a tool to help the following interactively:
(1) get interested in a block of text in a recent version;
(2) feed that to 'git log' like this:
git log -1 -p -S"$potentially_multi_line_text" $rev
this will find an old rev R whose parent R^ did not have the lines
in the exact form you fed with -S.
(3) inspect the output, and decide what to do next:
(3-a) you may want to adjust the text you look for, taking into
account how the neighbouring lines used to look like in R^, and run
another "git log -S" starting at R^; and/or
(3-b) you may want to run "git grep" for the text in the entire
tree in R^, to see if this was a code refactoring that consolidates
multiple copies of the same thing into a single place.
and go back to step (2).
cf. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
^ permalink raw reply
* [EGIT PATCH] Respect background when drawing history in SWT.
From: Robin Rosenberg @ 2008-11-05 0:40 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
Use transparent text background for drawing text to make the history
look nice when there is a background pattern or effects like alternating
background colors for each row.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../egit/ui/internal/history/CommitGraphTable.java | 2 +-
.../egit/ui/internal/history/SWTPlotRenderer.java | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java
index a28e3c4..2bccf99 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/CommitGraphTable.java
@@ -224,7 +224,7 @@ void doPaint(final Event event) {
final Point textsz = event.gc.textExtent(txt);
final int texty = (event.height - textsz.y) / 2;
- event.gc.drawString(txt, event.x, event.y + texty);
+ event.gc.drawString(txt, event.x, event.y + texty, true);
}
/**
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
index 23ec255..c4ee282 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
@@ -89,7 +89,7 @@ protected void drawText(final String msg, final int x, final int y) {
final int texty = (y * 2 - textsz.y) / 2;
g.setForeground(cellFG);
g.setBackground(cellBG);
- g.drawString(msg, cellX + x, cellY + texty);
+ g.drawString(msg, cellX + x, cellY + texty, true);
}
protected Color laneColor(final SWTLane myLane) {
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* Re: Git SVN Rebranching Issue
From: Avery Pennarun @ 2008-11-05 0:40 UTC (permalink / raw)
To: Eric Wong; +Cc: Dmitry Potapov, Matt Kern, git
In-Reply-To: <20081105003318.GA5666@hand.yhbt.net>
On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Dmitry Potapov <dpotapov@gmail.com> wrote:
>> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>> >
>> > Short answer: you can use grafts to remove parents.
>>
>> Using grafts requires some cautious, especially when it is used to make
>> some commits unreachable, because git gc can remove unreachable commits.
>> Also, a repository with grafts cannot be cloned. So using grafts looks
>> like more as workaround rather a real solution.
>
> I don't think extra history is harmful at all, so the grafts could even
> be temporary. AFAIK, the extra history is only an aesthetic issue in
> visualizers (and I actually like to see it myself).
But it's *lying* history in this case; it doesn't reflect what really
happened in svn *or* in real life. I'd say lying history is most
often harmful. "git blame" and "git log" will lie in this case, for
example.
>> Would it not be better to save the old branch using "@SVN-NUMBER" as
>> suffix? Thus, those do not need the old branch can easily delete it.
>
> That would require renaming _existing_ branches to their "@SVN-NUMBER"
> name; which would break mechanisms for tracking branches based on
> refname.
Well, you wouldn't have to rename the existing branch. You would
simply create the new @SVN-NUMBER branch when it became clear that
that commit is no longer reachable from the undecorated branch ref.
Isn't that why the @SVN-NUMBER branches are needed in the first place?
As for tracking branches based on refname, it seems like the current
behaviour of pretending to merge histories together wouldn't work too
well anyway. For someone pulling from the messed-up branch, they
really *will* need to rewind and re-pull, since that's exactly what
happened in svn. I don't think git has any chance of doing this
automatically just because of a new commit with two parents.
Disclaimer: I haven't run into any of this myself since I don't
recycle branch names in svn :)
Have fun,
Avery
^ permalink raw reply
* Re: Git SVN Rebranching Issue
From: Eric Wong @ 2008-11-05 0:33 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Matt Kern, git
In-Reply-To: <20081104094224.GC24100@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
> >
> > Short answer: you can use grafts to remove parents.
>
> Using grafts requires some cautious, especially when it is used to make
> some commits unreachable, because git gc can remove unreachable commits.
> Also, a repository with grafts cannot be cloned. So using grafts looks
> like more as workaround rather a real solution.
I don't think extra history is harmful at all, so the grafts could even
be temporary. AFAIK, the extra history is only an aesthetic issue in
visualizers (and I actually like to see it myself).
Besides, git svn is just a workaround until the SVN repository is
replaced entirely by git :)
> > It was actually an intentional design decision on my part preserve
> > parents based on branch name. We would eventually otherwise lose
> > history of the now-deleted branches, as reflogs can expire.
>
> Would it not be better to save the old branch using "@SVN-NUMBER" as
> suffix? Thus, those do not need the old branch can easily delete it.
That would require renaming _existing_ branches to their "@SVN-NUMBER"
name; which would break mechanisms for tracking branches based on
refname.
--
Eric Wong
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Bernt Hansen @ 2008-11-05 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vod0voy22.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>>
>>> Commits B, C, and D are not included in the git log -S output even
>>> though with gitk you can see that 'org-publish-validate-link' is in the
>>> patch.
>>
>> It is not sufficient for it to be in the patch, it has to be added or
>> deleted in whole. So for example if you had a line
>>
>> org-publish-validate-link Hello
>>
>> and you changed it to
>>
>> org-publish-validate-link World
>>
>> git log -SWorld will find the commit, but git log
>> -Sorg-publish-validate-link will not.
>
> It seems nobody has looked at the actual commits, but Dscho got it 80%
> right.
>
> There seems to be a misconception on what -S<foo> does. It does *NOT*
> grep for string <foo> in the patch text. It counts number of <foo> in
> preimage and postimage and decides that the commit is worth showing iff
> they differ.
>
> If you look at, for example (B):
>
> http://repo.or.cz/w/org-mode.git?a=commitdiff;h=837c81ce51
>
> You can see that in org-publish.el, org-publish-validate-link appears once
> as removed and once as added, so the total number of the appearance of the
> symbol in preimage and postimage are the same.
Now I get it :)
Thanks both of you!
Regards,
Bernt
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Bernt Hansen @ 2008-11-05 0:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811050014310.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>
>> Commits B, C, and D are not included in the git log -S output even
>> though with gitk you can see that 'org-publish-validate-link' is in the
>> patch.
>
> It is not sufficient for it to be in the patch, it has to be added or
> deleted in whole. So for example if you had a line
>
> org-publish-validate-link Hello
>
> and you changed it to
>
> org-publish-validate-link World
>
> git log -SWorld will find the commit, but git log
> -Sorg-publish-validate-link will not.
Ah I wasn't aware of that.
In this case the function 'org-publish-validate-link' was commented out,
and then in a later commit the comments were removed.
I was expecting these commits to be found by git log -S.
Thanks!
Bernt
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Bob Hiestand @ 2008-11-05 0:18 UTC (permalink / raw)
To: geoffrey.russell; +Cc: git, Johannes Schindelin
In-Reply-To: <93c3eada0811041449u20e0fc74gf6a1cb420923e484@mail.gmail.com>
On Tue, Nov 4, 2008 at 4:49 PM, Geoff Russell
<geoffrey.russell@gmail.com> wrote:
> Apologies to Johannes and Bob who have tried to help
> but I'm still having difficulties, here is my current non-working script:
>
> ------------------------------------------------------------------
> #!/bin/sh
> DIR=/tmp/gitdemo
> # for testing just arbitrarily
> # select the 15th most recent commit as our new origin
> NEWORIGIN=$(git rev-list master@{15} | head -1)
> echo $NEWORIGIN
> # checkout earlist point we are interested in
> # we want to drop any history before this point
> git checkout $NEWORIGIN
> # now make a new directory, initialise with new origin
> # and apply all commits after that point
> mkdir $DIR && (cd $DIR ; git init) && \
> rsync -aHv --exclude=.git ./ $DIR && \
> (cd $DIR ; git add . ; git commit -m "starting point" </dev/null ) && \
> git fast-export $NEWORIGIN..master | (cd $DIR ; git fast-import )
>
> ----------------- end of script
>
> The fast-import gives me a message I don't understand and doesn't
> do the import.
If I understood your requirement (I know nothing about fast-export),
it would look like this:
#!/bin/sh
DIR=/tmp/gitdemo
ORIGDIR=$PWD
git checkout -b shorthistory
NEWORIGIN=$(git rev-list --since='5 months ago' --reverse HEAD| head -1)
echo $NEWORIGIN
git filter-branch --parent-filter '
test $GIT_COMMIT = '$NEWORIGIN' &&
echo || cat' \
--tag-name-filter cat $NEWORIGIN^..
mkdir $DIR
cd $DIR
git init
git fetch $ORIGDIR shorthistory:master
Thank you,
bob
^ permalink raw reply
* Re: [PATCH v2 0/2] post-receive-email configurable rev display
From: Junio C Hamano @ 2008-11-04 23:55 UTC (permalink / raw)
To: Pete Harlan; +Cc: Andy Parkins, git
In-Reply-To: <1225783194-24640-1-git-send-email-pgit@pcharlan.com>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH] Makefile: add install-man rules (quick and normal)
From: Junio C Hamano @ 2008-11-04 23:55 UTC (permalink / raw)
To: markus.heidelberg; +Cc: gitster, git
In-Reply-To: <200811021853.03718.markus.heidelberg@web.de>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-04 23:55 UTC (permalink / raw)
To: Brandon Casey; +Cc: Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <muOuA1nLBoljLnZoguxeFeKt-8Q-I9Y3ljvxnLWLt9KyA8HwVtMa4Q@cipher.nrlssc.navy.mil>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-6-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Automatically turn --compose on when there is more than one patch, and
> that the output is a tty.
I do not think this is a good idea. I suspect I am not the only person
who uses "format-patch --cover-letter", edit the files to review and
prepare, and runs send-email to fire them off.
^ permalink raw reply
* Re: [PATCH 4/5] git send-email: ask less questions when --compose is used.
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-5-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> + print C <<EOT;
> +From $tpl_sender # This line is ignored.
> +GIT: Lines beginning in "GIT: " will be removed.
> +GIT: Consider including an overall diffstat or table of contents
> +GIT: for the patch you are writing.
> +GIT:
> +GIT: Clear the body content if you don't wish to send a summary.
> +From: $tpl_sender
> +Subject: $tpl_subject
> +In-Reply-To: $tpl_reply_to
> +
Somebody already suggested this but I really think GIT: lines should be at
the end and use '# ' prefix instead.
With the ability to give --cover-letter option to underlying format-patch
do you still need this?
> + my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
> +
> + if ($annotate) {
> + do_edit($compose_filename, @files);
> + } else {
> + do_edit($compose_filename);
> + }
Don't we want to abort the whole process when the user kills the editor
instead of normal exit (iow, do_edit() which is system() reports that the
editor was killed)?
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-3-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index aaace02..c29868a 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -22,8 +22,11 @@ use Term::ReadLine;
> use Getopt::Long;
> use Data::Dumper;
> use Term::ANSIColor;
> +use File::Temp qw/ tempdir /;
We seem to use File::Temp::tempdir already elsewhere, but they are in
archimport, cvsexportcommit and cvsserver, all of which are rather rarely
used ones. I think this is Perl 5.6.1 addition. Is everybody Ok with
this dependency? Just double checking.
> @@ -363,10 +366,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
>
> ($sender) = expand_aliases($sender) if defined $sender;
>
> +sub check_file_rev_conflict($) {
> + my $f = shift;
> + if ($repo->command('rev-parse', '--verify', '--quiet', $f)) {
> + die("revision/filename conflict on `$f'");
Perhaps wording this a bit more to the point? This is triggered when
'$f' can be both a filename or a revision, so...
File '$f' exists but it could also be the range of commits
to produce patches for. Please disambiguate by...
* Saying "./$f" if you mean a file; or
* Giving -F option if you mean a range.
Earlier I suggested that "origin^0" is a way for the user to disambiguate
favouring a rev, but such a filename can exist, so we cannot blindly
suggest to say "$f^0" here. I think adding -F (or --format-patch) option
to send-email to explicitly disable file/directory interpretation would be
a cleaner solution for this (and it would allow you to drive this from a
script without worrying about what garbage files you happen to have in the
working tree).
^ permalink raw reply
* Re: [(v2) PATCH 2/2] tag: Add more tests about mixing incompatible modes and options
From: Junio C Hamano @ 2008-11-04 23:47 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git
In-Reply-To: <20081104232036.19090.6085.stgit@arrakis.enst.fr>
Thanks; will queue.
^ 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