* 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] 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 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: 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: 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: 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 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 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
* [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 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
* 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: [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] 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: 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: 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: 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: [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: 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: 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: 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 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
* [PATCH/RFC] git-add--interactive.perl: Answer questions with a single keypress
From: Suraj N. Kurapati @ 2008-11-05 6:15 UTC (permalink / raw)
To: git
From aef6df163b90b9485da1f97a14ffab6d8de9b047 Mon Sep 17 00:00:00 2001
From: Suraj N. Kurapati <sunaku@gmail.com>
Date: Tue, 4 Nov 2008 20:32:34 -0800
Subject: [PATCH] git-add--interactive.perl: Answer questions with a single keypress
Allows the user to answer 'Stage this hunk' questions with a
single keypress, just like in Darcs. Previously, the user
was forced to press the Return key after every choice, which
quickly becomes tiring and burdensome work for the fingers.
Signed-off-by: Suraj N. Kurapati <sunaku@gmail.com>
---
git-add--interactive.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..1a22968 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -877,6 +877,7 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ require Term::ReadKey;
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
@@ -920,7 +921,10 @@ sub patch_update_file {
print;
}
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
- my $line = <STDIN>;
+
+ Term::ReadKey::ReadMode('raw');
+ my $line = Term::ReadKey::ReadKey(0);
+ Term::ReadKey::ReadMode('restore');
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
--
1.6.0.3
\0
^ permalink raw reply related
* Re: [PATCH/RFC v2] git-add--interactive.perl: Answer questions with a single keypress
From: Suraj N. Kurapati @ 2008-11-05 6:31 UTC (permalink / raw)
To: git
In-Reply-To: <200811042215.31147.sunaku@gmail.com>
Allows the user to answer 'Stage this hunk' questions with a
single keypress, just like in Darcs. Previously, the user was
forced to press the Return key after every choice they made.
This quickly becomes tiring, burdensome work for the fingers.
Signed-off-by: Suraj N. Kurapati <sunaku@gmail.com>
---
git-add--interactive.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..a824984 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -877,6 +877,8 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ require Term::ReadKey;
+ Term::ReadKey::ReadMode('raw');
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
@@ -920,7 +922,7 @@ sub patch_update_file {
print;
}
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
- my $line = <STDIN>;
+ my $line = Term::ReadKey::ReadKey(0);
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
@@ -998,6 +1000,7 @@ sub patch_update_file {
}
}
}
+ Term::ReadKey::ReadMode('restore');
my $n_lofs = 0;
my @result = ();
--
1.6.0.3
\0
^ permalink raw reply related
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-05 6:40 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, Dmitry Potapov, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <20081105030525.GC20907@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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.
That is not good enough.
People who (think) know what an unconfigured "git push" would do would
suddenly see "git push" start misbehaving in their new repositories.
Here is a patch to do what I suggested earlier. It
* Adds "--matching" option; if we ever change the default to "current
branch only", then "git push $there :" forces people to type $there.
"git push --matching" allows us to honor "branch.<name>.remote".
* Issues a deprecation warning when "git push" and "git push $there" is
used to trigger the "matching" behaviour, without configuration or
explicit command line refspec ":".
Whoever wants to change the default to "current branch only" can change
the part that calls push_deprecation_warning().
I'll leave it up to people who want to change the default to implement the
same for non native transports and document the transition plan, as I am
not very keen on changing the default myself.
---
builtin-push.c | 11 +++++++----
builtin-send-pack.c | 2 ++
remote.c | 8 ++++++++
remote.h | 1 +
send-pack.h | 1 +
transport.c | 1 +
transport.h | 1 +
7 files changed, 21 insertions(+), 4 deletions(-)
diff --git c/builtin-push.c w/builtin-push.c
index 122fdcf..21418ab 100644
--- c/builtin-push.c
+++ w/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [--dry-run] [--matching] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -71,9 +71,11 @@ static int do_push(const char *repo, int flags)
return error("--mirror can't be combined with refspecs");
}
- if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
- (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
- return error("--all and --mirror are incompatible");
+ if (HAS_MULTI_BITS(flags &
+ (TRANSPORT_PUSH_ALL|
+ TRANSPORT_PUSH_MIRROR|
+ TRANSPORT_PUSH_MATCHING))) {
+ return error("--all, --mirror, --matching are incompatible");
}
if (!refspec
@@ -123,6 +125,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
+ OPT_BIT( 0 , "matching", &flags, "push matching", TRANSPORT_PUSH_MATCHING),
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
diff --git c/builtin-send-pack.c w/builtin-send-pack.c
index d68ce2d..f5dda88 100644
--- c/builtin-send-pack.c
+++ w/builtin-send-pack.c
@@ -402,6 +402,8 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
flags |= MATCH_REFS_ALL;
if (args.send_mirror)
flags |= MATCH_REFS_MIRROR;
+ if (args.send_matching)
+ flags |= MATCH_REFS_MATCHING;
/* No funny business with the matcher */
remote_tail = get_remote_heads(in, &remote_refs, 0, NULL, REF_NORMAL,
diff --git c/remote.c w/remote.c
index e530a21..ce4f54c 100644
--- c/remote.c
+++ w/remote.c
@@ -1017,6 +1017,12 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
return NULL;
}
+static void push_deprecation_warning(void)
+{
+ warning("'git push [$remote]' will stop pushing 'matching refs' in a future release");
+ warning("please train your fingers to say 'git push --matching' instead.");
+}
+
/*
* Note. This is used only by "push"; refspec matching rules for
* push and fetch are subtly different, so do not try to reuse it
@@ -1031,6 +1037,8 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
static const char *default_refspec[] = { ":", 0 };
if (!nr_refspec) {
+ if (!(flags & MATCH_REFS_MATCHING))
+ push_deprecation_warning();
nr_refspec = 1;
refspec = default_refspec;
}
diff --git c/remote.h w/remote.h
index d2e170c..2a702cb 100644
--- c/remote.h
+++ w/remote.h
@@ -124,6 +124,7 @@ enum match_refs_flags {
MATCH_REFS_NONE = 0,
MATCH_REFS_ALL = (1 << 0),
MATCH_REFS_MIRROR = (1 << 1),
+ MATCH_REFS_MATCHING = (1 << 2),
};
/* Reporting of tracking info */
diff --git c/send-pack.h w/send-pack.h
index 8ff1dc3..133cb67 100644
--- c/send-pack.h
+++ w/send-pack.h
@@ -6,6 +6,7 @@ struct send_pack_args {
unsigned verbose:1,
send_all:1,
send_mirror:1,
+ send_matching:1,
force_update:1,
use_thin_pack:1,
dry_run:1;
diff --git c/transport.c w/transport.c
index 56831c5..4057d27 100644
--- c/transport.c
+++ w/transport.c
@@ -680,6 +680,7 @@ static int git_transport_push(struct transport *transport, int refspec_nr, const
args.receivepack = data->receivepack;
args.send_all = !!(flags & TRANSPORT_PUSH_ALL);
args.send_mirror = !!(flags & TRANSPORT_PUSH_MIRROR);
+ args.send_matching = !!(flags & TRANSPORT_PUSH_MATCHING);
args.force_update = !!(flags & TRANSPORT_PUSH_FORCE);
args.use_thin_pack = data->thin;
args.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);
diff --git c/transport.h w/transport.h
index 6bbc1a8..fb98128 100644
--- c/transport.h
+++ w/transport.h
@@ -34,6 +34,7 @@ struct transport {
#define TRANSPORT_PUSH_DRY_RUN 4
#define TRANSPORT_PUSH_MIRROR 8
#define TRANSPORT_PUSH_VERBOSE 16
+#define TRANSPORT_PUSH_MATCHING 32
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
^ permalink raw reply related
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Junio C Hamano @ 2008-11-05 7:03 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, git
In-Reply-To: <20081105033151.GB24886@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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).
Yeah, if send-email did not have --compose to begin with, we could just
say "don't use --compose; use --cover-letter when you use send-email to
front-end format-patch instead", but some people perhaps are used to run
format-patch separately without --cover-letter and then create the cover
letter from scratch with --compose (which seems a bit more work to me,
though).
So I am not opposed to a sendemail.foo configuration option.
^ 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