* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 19:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810280755570.3386@nehalem.linux-foundation.org>
On Tue, Oct 28, 2008 at 08:17:02AM -0700, Linus Torvalds wrote:
> > - Does it make sense to have this _in addition_ to --decorate (since
> > for any commit with a --decorate field, it would likely be the same
> > as --source)? Should it be a different type of decorate instead,
> > like --decorate=source or --decorate=branch?
>
> I think they are different. People who want --source generally have other
> issues than people who want --decorate, and the two do actually work
> together.
Sleeping on this and thinking about it some more, I think you are right
here, and all of the other complaints I had just go away.
I was thinking of it as "decorate commits with the likely branches they
were made on." But that's not what this is at all (though it happens to
come up with similar answers!). It's really about "show which ref, of
the refs which were requested to be shown, we started at to reach this
commit." Which is perhaps more limited, but obvoiusly is much faster to
compute.
And then the output of "git log --source HEAD" makes perfect sense, and
it makes sense not to worry about finding the "closest" ref. It is
really about annotating the traversal that you asked for.
So now my only complaint is the lack of documentation and tests. ;)
-Peff
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Randal L. Schwartz @ 2008-10-28 19:16 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Arne Babenhauserheide, Miklos Vajna, Jakub Narebski, git,
mercurial, SLONIK.AZ
In-Reply-To: <4907506C.8090609@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
Andreas> And please don't give me that rubbish of "but Python is obviously
Andreas> better than C". Which one's true (if any) depends only on how you
Andreas> define "better".
But any way you define it, Perl is "better" than either of those!
:-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: [RFC PATCH v2] fetch-pack: log(n)-transmission find_common()
From: Thomas Rast @ 2008-10-28 19:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <alpine.LFD.2.00.0810281034500.13034@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Nicolas Pitre wrote:
>
> FWIW, I had to back this patch out from my version as things seemed to
> fall into an infinite loop of ref negotiation while fetching the Linux
> kernel repository at some point. Doing a "git fetch -v -v" turned up an
> endless stream of "got" and "have" lines. I was in a hurry for $work so
> didn't think of preserving my local refs for reproduction of the
> problem.
Ah. Thanks for the report, though having a test case would be great.
I've been running it without problems since I completed v2 more than a
month ago, so I don't expect it to be an obvious mistake.
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: SZEDER Gábor @ 2008-10-28 19:38 UTC (permalink / raw)
To: Arne Babenhauserheide
Cc: Andreas Ericsson, Miklos Vajna, Jakub Narebski, git, mercurial,
SLONIK.AZ
In-Reply-To: <200810282011.40647.arne_bab@web.de>
On Tue, Oct 28, 2008 at 08:11:36PM +0100, Arne Babenhauserheide wrote:
> > How many perl gurus have skipped writing
> > stuff for hg because it's a "python-or-bust" thing?
>
> How many Python people decided to write an extension for hg, because it can
> very nicely be accessed via Python?
And wouldn't they contribute at all, if there would be hg bindings for
other programming languages, would they?
Best,
Gábor
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 19:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028131116.GA8272@artemis.googlewifi.com>
On Tue, Oct 28, 2008 at 02:11:16PM +0100, Pierre Habouzit wrote:
> Actually I tried to do that (and you meant name-rev --contains rather
> than describe actually ;p), and I stopped because it's too slow. I
I think we are both wrong, since it's "git describe --contains". ;)
But yes, that was what I meant.
> believe the proper way to do that is to help git-log knowing which are
> the short (topic) branches, and to crawl incrementally using a
> date-based hack. This would basically work a bit like this. Let's
> imaging you want to crawl "next" in git and know which topics from pu
> are in it. You would say e.g.:
Hmm. Why a date-based hack to see what's on the topic branch? Why not
just give an option to walk the graph twice, giving name-rev style
annotations, and just let it be slow. People will mostly look at it by
specifying just their topic branches anyway. IOW:
git log ^origin/master my/topic1 my/topic2 my/topic3
and by virtue of the fact that you are vastly limiting the size of the
tree, it won't actually end up too slow. So you haven't said so much
"these are my topic branches" as "I am just not interested in things
that are already upstream."
Or maybe I'm misunderstanding something here:
> Then one has to know which are the heads of every topic branches first,
> then crawl next the usual way, except that when you arrive to a point
> that is a topic branch head, you don't look that way. You remember the
> date of that point, and continue to crawl "next" a bit further so that
> you can start annotating the topic's commits you've stumbled upon. And
> you do that, you look at jd/topic (as in John Doe topic branch) and mark
> all the commits as being from jd/topic, until you either go back to some
> commit from next, or your current commit date is younger than your
> current "next" crawling front. In the former case, you're done with that
> topic, in the latter you must continue to preprocess "next" a bit more.
When you say "heads of topic branches" do you mean we actually have the
topic branches? Or do you mean you want to crawl next, pulling the names
of the topic branches from the merge messages?
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 19:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028194642.GB752@sigill.intra.peff.net>
On Tue, Oct 28, 2008 at 03:46:43PM -0400, Jeff King wrote:
>
> Hmm. Why a date-based hack to see what's on the topic branch? Why not
> just give an option to walk the graph twice, giving name-rev style
> annotations, and just let it be slow. People will mostly look at it by
> specifying just their topic branches anyway. IOW:
>
> git log ^origin/master my/topic1 my/topic2 my/topic3
And obviously you could split the "these are the commits to annotate"
specification from "these are the commits to show". But I actually think
in practice most users would want those to be the same.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Pierre Habouzit @ 2008-10-28 20:09 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028194642.GB752@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
On Tue, Oct 28, 2008 at 07:46:43PM +0000, Jeff King wrote:
> On Tue, Oct 28, 2008 at 02:11:16PM +0100, Pierre Habouzit wrote:
> > believe the proper way to do that is to help git-log knowing which are
> > the short (topic) branches, and to crawl incrementally using a
> > date-based hack. This would basically work a bit like this. Let's
> > imaging you want to crawl "next" in git and know which topics from pu
> > are in it. You would say e.g.:
>
> Hmm. Why a date-based hack to see what's on the topic branch? Why not
> just give an option to walk the graph twice,
it serves the purpose to not walk the graph twice actually, but indeed
twice is not _that_ bad.
> giving name-rev style annotations, and just let it be slow. People
> will mostly look at it by specifying just their topic branches anyway.
> IOW:
>
> git log ^origin/master my/topic1 my/topic2 my/topic3
>
> and by virtue of the fact that you are vastly limiting the size of the
> tree, it won't actually end up too slow. So you haven't said so much
> "these are my topic branches" as "I am just not interested in things
> that are already upstream."
Well, I was just thinking quickly during jetlag-induced insomnia. I
don't really care about the issue that much actually.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Add a 'source' decorator for commits
From: Jeff King @ 2008-10-28 20:27 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20081028200901.GA2894@artemis.mtv.corp.google.com>
On Tue, Oct 28, 2008 at 09:09:02PM +0100, Pierre Habouzit wrote:
> > Hmm. Why a date-based hack to see what's on the topic branch? Why not
> > just give an option to walk the graph twice,
>
> it serves the purpose to not walk the graph twice actually, but indeed
> twice is not _that_ bad.
Sure, and that is reasonable. But I think the real goal is "give this
information in a not-painfully slow manner". So if we can do it by
walking a smaller graph twice, I think that is OK, too.
> Well, I was just thinking quickly during jetlag-induced insomnia. I
> don't really care about the issue that much actually.
Heh. I have to admit I don't care enough to work on this personally,
either. I just _thought_ Linus was working on it, but I think what he is
doing is subtly different, and our discussion has diverged to something
that, if it ever came to pass, would be a separate feature.
-Peff
^ permalink raw reply
* [StGit PATCH] Tutorial: Importing patches
From: Karl Hasselström @ 2008-10-28 20:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 89 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 2808462..283b358 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -621,7 +621,94 @@ get rid of such empty patches if you don't want them hanging around:
Importing patches
-----------------
-TODO:: import, ...
+While you are busy producing patches, there's hopefully someone -- the
+'maintainer' -- at the other end who recieves them and 'applies' them
+to her Git tree, which is then published for all (or parts of) the
+world to see.
+
+It's perfectly fine for this person to not have the foggiest idea what
+StGit is. In that case, she'll probably apply your patches with
+something like +git am+, and everything will just work, exactly as if
+you'd used Git to send those patches. But she might be an StGit user
+too, in which case she might use stglink:import[].
+
+There are basically four kinds if stuff you can import with
+stglink:import[]:
+
+ 1. A patch in a file.
+
+ 2. Several files containing one patch each, and a 'series' file
+ listing those other files in the correct order.
+
+ 3. An e-mail containing a single patch.
+
+ 4. A mailbox file (in standard Unix +mbox+ format) containing
+ multiple e-mails with one patch in each.
+
+
+Importing a plain patch
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Importing a plain patch, such as produced by e.g. GNU +diff+, +git
+diff+, +git show+, stglink:diff[], or stglink:show[], is very easy.
+Just say
+
+ $ stg import my-patch
+
+and you'll have a new patch at the top of your stack.
+
+If you don't give a file name on the command line, stglink:import[]
+will read the patch from its standard input -- in other words, you can
+pipe a patch to it directly from the command that produces it.
+
+By default, the new patch's name will be taken from the file name, and
+its commit message and author info will be taken from the beginning of
+the patch, if they are there. However, there are command line switches
+to override all of these things; see the man page for details.
+
+
+Importing several patches at once
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some programs -- among them stglink:export[] -- will create a bunch of
+files with one patch in each, and a 'series' file (often called
++series+) listing the other files in the correct order. Give
++$$--series$$+ and the name of the series file to stglink:import[],
+and it will import all the patches for you, in the correct order.
+
+
+Importing a patch from an e-mail
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Importing a patch from an e-mail is simple too:
+
+ $ stg import --mail my-mail
+
+The e-mail should be in standard Git mail format (which is what e.g.
+stglink:mail[] produces) -- that is, with the patch in-line in the
+mail, not attached. The authorship info is taken from the mail
+headers, and the commit message is read from the 'Subject:' line and
+the mail body.
+
+If you don't give a file name, the mail will be read from the standard
+input. This means that, if your mail reader supports it, you can pipe
+a mail directly to +stg import $$--mail$$+ and the patch will be
+applied.
+
+
+Importing a mailbox full of patches
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Finally, in case importing one patch at a time is too much work,
+stglink:import[] also accepts an entire Unix +mbox+-format mailbox,
+either on the command line or on its standard input; just use the
++$$--mbox$$+ flag. Each mail should contain one patch, and is imported
+just like with +$$--mail$$+.
+
+Mailboxes full of patches are produced by e.g. stglink:mail[] with the
++$$--mbox$$+ flag, but most mail readers can produce them too, meaning
+that you can copy all the patch mails you want to apply to a separate
+mailbox, and then import them all in one go.
Other stuff that needs to be placed somewhere
^ permalink raw reply related
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Christian Couder @ 2008-10-28 19:13 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83skqg1uc9.fsf@kalahari.s2.org>
On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
> "Christian Couder" <christian.couder@gmail.com> writes:
>
>> Hi,
>>
>> On Tue, Oct 28, 2008 at 5:28 PM, Hannu Koivisto <azure@iki.fi> wrote:
>>> Greetings,
>>>
>>> git bisect view uses gitk if DISPLAY environment variable is set
>>> and git log otherwise. Since gitk doesn't require X server in
>>> Cygwin, that seems like a bit questionable condition in that
>>> environment.
>>
>> Do you know any environment variable that we could use to detect we
>> can use gitk in Cygwin?
>
> I looked around and I believe there is no such variable. I suppose
> the only case where you cannot use gitk is when the user is logged
> on using ssh, telnet, psexec or similar (well, unless you use some
> non-standard Tcl/Tk build which is configured to use X instead of
> Windows graphics). Then again, I don't think typical Windows
> programs do any checks for such situations.
We need at least a way to detect we are under Cygwin, because we won't
change the current behavior for all platforms.
Is checking for the CYGWIN environment variable enough?
> So, easy fix: always use gitk unless log is specified. Harder fix:
> figure out a way to test if the login session is such that
> graphical applications can be run.
>
>> You can use "git bisect view log" to use "git log" even if DISPLAY is set.
>
> I'd rather not use undocumented functionality ;)
In this case you can use any "git log" option after "git bisect view"
(for example: git bisect view -p).
Regards,
Christian.
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Miklos Vajna @ 2008-10-28 21:10 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Peter Krefting, Git Mailing List
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> To sum up, I'm not so sure about a working hg fast-import is available
> at the moment.
I wrote too fast.
There is a minimal implementation here:
http://hg.opensource.lshift.net/hg-fastimport/
(I haven't tried it yet myself.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: error pushing stash ?
From: Jeff King @ 2008-10-28 21:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Bryson, git
In-Reply-To: <20081007004051.GA18889@spearce.org>
On Mon, Oct 06, 2008 at 05:40:51PM -0700, Shawn O. Pearce wrote:
> > ! [remote rejected] refs/stash -> refs/stash (funny refname)
> > error: failed to push some refs to '/users/dbryson/backup/janus.git/'
>
> refs/stash is a funny refname because it contains only 1 '/'.
> Normally a valid ref has at least 2 '/', e.g. refs/heads/8654 or
> refs/tags/v1.0.
Since no version of receive-pack accepts these "funny refs", perhaps we
should mirror the check when considering the list of refs to send. IOW,
don't even make them eligible for matching or mirroring. Patch is below.
> Naming the stash refs/stash was perhaps funny in the first place
> since it cannot be moved about on the transport protocol, but then
> again the bulk of the stash data is actually in the reflog for the
> stash (and not the stash ref itself) so there is basically no point
> in pushing or fetching a stash directly.
I agree there is not much point in pushing it, since the useful bit is
in the reflog. So perhaps a "funny" refname is a good place to put it,
since it easily tells us that it is not a useful thing to push.
---
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index bbf6e0a..298bd71 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -140,7 +140,13 @@ static struct ref *remote_refs, **remote_tail;
static int one_local_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
struct ref *ref;
- int len = strlen(refname) + 1;
+ int len;
+
+ /* we already know it starts with refs/ to get here */
+ if (check_ref_format(refname + 5))
+ return 0;
+
+ len = strlen(refname) + 1;
ref = xcalloc(1, sizeof(*ref) + len);
hashcpy(ref->new_sha1, sha1);
memcpy(ref->name, refname, len);
^ permalink raw reply related
* Re: error pushing stash ?
From: Jeff King @ 2008-10-28 21:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Bryson, git
In-Reply-To: <20081028211755.GA8074@sigill.intra.peff.net>
On Tue, Oct 28, 2008 at 05:17:55PM -0400, Jeff King wrote:
> Since no version of receive-pack accepts these "funny refs", perhaps we
> should mirror the check when considering the list of refs to send. IOW,
> don't even make them eligible for matching or mirroring. Patch is below.
> [...]
> + /* we already know it starts with refs/ to get here */
> + if (check_ref_format(refname + 5))
> + return 0;
It occurs to me that since I didn't give a good commit message, and
since I replied to a several-weeks-old message, this might be confusing.
But what I am suggesting is that git-push should not bother trying to
send something that it knows git-receive-pack will refuse. So this check
goes into builtin-send-pack.c, and is an exact mirror of the one in
builtin-receive-pack.c:
$ sed -n 177,181p builtin-receive-pack.c
/* only refs/... are allowed */
if (prefixcmp(name, "refs/") || check_ref_format(name + 5)) {
error("refusing to create funny ref '%s' remotely", name);
return "funny refname";
}
-Peff
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Theodore Tso @ 2008-10-28 21:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Pieter de Bie, Peter Krefting, Git Mailing List
In-Reply-To: <20081028191234.GS24201@genesis.frugalware.org>
On Tue, Oct 28, 2008 at 08:12:34PM +0100, Miklos Vajna wrote:
> On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <pdebie@ai.rug.nl> wrote:
> > fast-import yet. If I understand dscho correctly, that exists now, so it
> > should be easy enough to integrate that as well.
>
> That's new to me. Theodore Ts'o once mentioned on this list that there
> is a "hg fast-export" but actually he just referred to "there is a
> git2hg conversion tool in hg's contrib dir" and it has nothing with
> fast-import.
The code I was referring to was called hg-fast-export, which is part
of the "fast export" tools that front-end into git fast-import. The
git repository can be found here:
http://repo.or.cz/w/fast-export.git
git://repo.or.cz/fast-export.git
I ended up using a very customized version of that script to convert
the hg e2fsprogs repository to git.
In the past I've looked at the possibility of creating a
bi-directional, incremental gateway between hg and git repositories.
The main thing which makes this difficult is that hg stores tags
in-band inside the change-controlled .hgtags file. This means that if
you cut a release, tag it, and then create a commit to further modify
the repository, the new commit is descended from the tag commit,
whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,
but not part of the revision history.
I think the git method is much more sane, but what it means is that
topologically, the commit tree for git and hg can never be identical.
It also means that if you add a tag to a git tree after making several
commits on that branch, how you reflect that in the hg repository is
highly problematic. Do you rewrite the branch? Do you add the tag
later on, disturbing the parent-child relationship of later commits?
How do you keep track of when a tag hg repository topology if you are
trying to maintain a bidirectional mapping between commits?
It's not impossible, but it makes it much more difficult, since in the
hg world, tag commits can be inserted between arbitrary commits. This
also means that if you want to create a bidrectional gateway between
hg and git, it has to be a single gateway so it can keep track of this
state information. If you try to have multiple gateways they would
need to synchronize on when a tag entered the hg universe, and with
what commit ID (and what timestamp).
- Ted
^ permalink raw reply
* Re: [StGit PATCH] Tutorial: Importing patches
From: Catalin Marinas @ 2008-10-28 22:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081028204223.9539.89315.stgit@yoghurt>
Hi Karl,
Thanks for the patch.
2008/10/28 Karl Hasselström <kha@treskal.com>:
> +Importing a patch from an e-mail is simple too:
> +
> + $ stg import --mail my-mail
> +
> +The e-mail should be in standard Git mail format (which is what e.g.
> +stglink:mail[] produces) -- that is, with the patch in-line in the
> +mail, not attached. The authorship info is taken from the mail
> +headers, and the commit message is read from the 'Subject:' line and
> +the mail body.
It actually supports importing diffs from attachments as well as long
as they are text/plain (the description is expected in the mail body).
Anyway, I think we don't have to mention this in the tutorial as most
people would use the Git mail format anyway.
--
Catalin
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-28 22:37 UTC (permalink / raw)
To: git
In-Reply-To: <c07716ae0810281213k432d82d8i468f54ae03146b88@mail.gmail.com>
"Christian Couder" <christian.couder@gmail.com> writes:
> On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> "Christian Couder" <christian.couder@gmail.com> writes:
> We need at least a way to detect we are under Cygwin, because we won't
> change the current behavior for all platforms.
> Is checking for the CYGWIN environment variable enough?
No, because it may not be set. I would probably do it at compile
time using __CYGWIN__ definition. I don't know what's the status
of merging MSysGit with "official" git but I suppose that when that
happens, __MING32__ and/or _WIN32 or something would need to be
considered as well.
>>> You can use "git bisect view log" to use "git log" even if DISPLAY is set.
>>
>> I'd rather not use undocumented functionality ;)
>
> In this case you can use any "git log" option after "git bisect view"
> (for example: git bisect view -p).
I was implying that "log" after "git bisect view" is not documented
by git-bisect(1). "log" is not a "git log" option.
--
Hannu
^ permalink raw reply
* Any way to amend AuthorDate?
From: Jing Xue @ 2008-10-28 20:06 UTC (permalink / raw)
To: git
Is there any way to amend a commit and change only the Author Date?
For instance, I have a binary file that's been checked in in two
consecutive commits. After squashing them into one, the new commit would
keep the timestamp of the earlier one of the two original commits. I
would like it to have either the later timestamp or whenever the squash
happens.
Thanks for any pointers.
--
Jing Xue
^ permalink raw reply
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Hannu Koivisto @ 2008-10-28 23:26 UTC (permalink / raw)
To: git
In-Reply-To: <83iqrccpmk.fsf@kalahari.s2.org>
Hannu Koivisto <azure@iki.fi> writes:
> "Christian Couder" <christian.couder@gmail.com> writes:
>
>> On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
>>> "Christian Couder" <christian.couder@gmail.com> writes:
>
>> We need at least a way to detect we are under Cygwin, because we won't
>> change the current behavior for all platforms.
>> Is checking for the CYGWIN environment variable enough?
>
> No, because it may not be set. I would probably do it at compile
> time using __CYGWIN__ definition. I don't know what's the status
Argh, I didn't realize git-bisect is a shell script. For detecting
Cygwin in shell scripts I have tested if `uname` matches CYGWIN*.
For detecting Windows I have tested if PROCESSOR_ARCHITECTURE is
set. There may well be better ways.
--
Hannu
^ permalink raw reply
* Re: Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial)
From: Miklos Vajna @ 2008-10-28 23:28 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pieter de Bie, Peter Krefting, Git Mailing List
In-Reply-To: <20081028213144.GC10862@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
On Tue, Oct 28, 2008 at 05:31:44PM -0400, Theodore Tso <tytso@mit.edu> wrote:
> The code I was referring to was called hg-fast-export, which is part
> of the "fast export" tools that front-end into git fast-import. The
> git repository can be found here:
>
> http://repo.or.cz/w/fast-export.git
> git://repo.or.cz/fast-export.git
>
> I ended up using a very customized version of that script to convert
> the hg e2fsprogs repository to git.
My bad, I did not quote the article properly, so here is what I meant:
http://article.gmane.org/gmane.comp.version-control.git/42298
and I just wanted to say that this one does not use fast-import, so it's
not really a "hg-fast-import" (it's not something that can parse the
output of git-fast-export).
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: David Symonds @ 2008-10-28 23:39 UTC (permalink / raw)
To: git, gitster; +Cc: David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
This isn't a particularly serious patch, but is very relevant to our
current discussion at GitTogether '08.
.gitignore | 1 +
Makefile | 1 +
git-staged.sh | 8 ++++++++
3 files changed, 10 insertions(+), 0 deletions(-)
create mode 100755 git-staged.sh
diff --git a/.gitignore b/.gitignore
index bbaf9de..9353d19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
+git-staged
git-stash
git-status
git-stripspace
diff --git a/Makefile b/Makefile
index d6f3695..1b23e53 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,7 @@ SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-staged.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
diff --git a/git-staged.sh b/git-staged.sh
new file mode 100755
index 0000000..bfd36e7
--- /dev/null
+++ b/git-staged.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+USAGE=''
+SUBDIRECTORY_OK='Yes'
+OPTIONS_SPEC=
+. git-sh-setup
+
+git diff --cached
--
1.6.0
^ permalink raw reply related
* Re: [PATCH 0/3] symref rename/delete fixes
From: Miklos Vajna @ 2008-10-28 23:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1225136865.git.vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Mon, Oct 27, 2008 at 08:50:19PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> Here they are. The first is updated: the delete_ref() part is unchanged,
> but the rename_ref() part is dropped and it just bails out with an error
> if it detects a symref. The testcase is updated according to this as
> well.
>
> The two others are just rebased on top of the new first one, no
> functional changes.
I forgot to fetch and did not notice the previous round is already in
'next'. Just forget about these patches then, I'll rebase the relevant
part against mv/maint-branch-m-symref and resend.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: Jeff King @ 2008-10-28 23:46 UTC (permalink / raw)
To: David Symonds; +Cc: git, gitster
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
On Tue, Oct 28, 2008 at 04:39:05PM -0700, David Symonds wrote:
> --- /dev/null
> +++ b/git-staged.sh
> @@ -0,0 +1,8 @@
> +#!/bin/sh
> +
> +USAGE=''
> +SUBDIRECTORY_OK='Yes'
> +OPTIONS_SPEC=
> +. git-sh-setup
> +
> +git diff --cached
Do you even need to do sh-setup? How about
#!/bin/sh
exec git diff --cached "$@"
-Peff
^ permalink raw reply
* [PATCH] Implement git-staged, an alias for 'git diff --cached'.
From: David Symonds @ 2008-10-28 23:59 UTC (permalink / raw)
To: git, gitster, Jeff King; +Cc: David Symonds
In-Reply-To: <1225237145-95435-1-git-send-email-dsymonds@gmail.com>
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
.gitignore | 1 +
Makefile | 1 +
git-staged.sh | 2 ++
3 files changed, 4 insertions(+), 0 deletions(-)
create mode 100755 git-staged.sh
diff --git a/.gitignore b/.gitignore
index bbaf9de..9353d19 100644
--- a/.gitignore
+++ b/.gitignore
@@ -118,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
+git-staged
git-stash
git-status
git-stripspace
diff --git a/Makefile b/Makefile
index d6f3695..1b23e53 100644
--- a/Makefile
+++ b/Makefile
@@ -262,6 +262,7 @@ SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-staged.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
diff --git a/git-staged.sh b/git-staged.sh
new file mode 100755
index 0000000..85582ec
--- /dev/null
+++ b/git-staged.sh
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec git diff --cached $*
--
1.6.0
^ permalink raw reply related
* [PATCH] git branch -m: forbid renaming of a symref
From: Miklos Vajna @ 2008-10-29 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <20081028234541.GY24201@genesis.frugalware.org>
There may be cases where one would really want to rename the symbolic
ref without changing its value, but "git branch -m" is not such a
use-case.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
This applies on top of 'mv/maint-branch-m-symref'.
refs.c | 29 +++++++++++++----------------
t/t3200-branch.sh | 8 ++++----
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/refs.c b/refs.c
index b39e6f2..8a38e08 100644
--- a/refs.c
+++ b/refs.c
@@ -964,14 +964,14 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
struct stat loginfo;
int log = !lstat(git_path("logs/%s", oldref), &loginfo);
const char *symref = NULL;
- int is_symref = 0;
if (log && S_ISLNK(loginfo.st_mode))
return error("reflog for %s is a symlink", oldref);
symref = resolve_ref(oldref, orig_sha1, 1, &flag);
if (flag & REF_ISSYMREF)
- is_symref = 1;
+ return error("refname %s is a symbolic ref, renaming it is not supported",
+ oldref);
if (!symref)
return error("refname %s not found", oldref);
@@ -1035,20 +1035,17 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
}
logmoved = log;
- if (!is_symref) {
- lock = lock_ref_sha1_basic(newref, NULL, 0, NULL);
- if (!lock) {
- error("unable to lock %s for update", newref);
- goto rollback;
- }
- lock->force_write = 1;
- hashcpy(lock->old_sha1, orig_sha1);
- if (write_ref_sha1(lock, orig_sha1, logmsg)) {
- error("unable to write current sha1 into %s", newref);
- goto rollback;
- }
- } else
- create_symref(newref, symref, logmsg);
+ lock = lock_ref_sha1_basic(newref, NULL, 0, NULL);
+ if (!lock) {
+ error("unable to lock %s for update", newref);
+ goto rollback;
+ }
+ lock->force_write = 1;
+ hashcpy(lock->old_sha1, orig_sha1);
+ if (write_ref_sha1(lock, orig_sha1, logmsg)) {
+ error("unable to write current sha1 into %s", newref);
+ goto rollback;
+ }
return 0;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index fdeb1f5..25e9971 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -112,13 +112,13 @@ test_expect_success 'config information was renamed, too' \
"test $(git config branch.s.dummy) = Hello &&
test_must_fail git config branch.s/s/dummy"
-test_expect_success 'renaming a symref' \
+test_expect_success 'renaming a symref is not allowed' \
'
git symbolic-ref refs/heads/master2 refs/heads/master &&
- git branch -m master2 master3 &&
- git symbolic-ref refs/heads/master3 &&
+ test_must_fail git branch -m master2 master3 &&
+ git symbolic-ref refs/heads/master2 &&
test -f .git/refs/heads/master &&
- ! test -f .git/refs/heads/master2
+ ! test -f .git/refs/heads/master3
'
test_expect_success \
--
1.6.0.2
^ permalink raw reply related
* Re: git bisect view's use of DISPLAY environment variable in Cygwin
From: Johannes Schindelin @ 2008-10-29 0:46 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83ej20cndw.fsf@kalahari.s2.org>
Hi,
On Wed, 29 Oct 2008, Hannu Koivisto wrote:
> Hannu Koivisto <azure@iki.fi> writes:
>
> > "Christian Couder" <christian.couder@gmail.com> writes:
> >
> >> On Tue, Oct 28, 2008 at 6:51 PM, Hannu Koivisto <azure@iki.fi> wrote:
> >>> "Christian Couder" <christian.couder@gmail.com> writes:
> >
> >> We need at least a way to detect we are under Cygwin, because we
> >> won't change the current behavior for all platforms. Is checking for
> >> the CYGWIN environment variable enough?
> >
> > No, because it may not be set. I would probably do it at compile time
> > using __CYGWIN__ definition. I don't know what's the status
>
> Argh, I didn't realize git-bisect is a shell script. For detecting
> Cygwin in shell scripts I have tested if `uname` matches CYGWIN*. For
> detecting Windows I have tested if PROCESSOR_ARCHITECTURE is set.
> There may well be better ways.
I submitted a patch a while ago, saying
bisect view: call gitk if Cygwin's SESSIONNAME variable is set
See
http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=a2637a3a003646c69ab5a6b85f0ee1bfac15e0b0
Ciao,
Dscho
^ 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