* Re: rebase-with-history -- a technique for rebasing without trashing your repo history
From: Michael Haggerty @ 2009-08-13 22:39 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Git Mailing List
In-Reply-To: <20090813161256.GA8292@atjola.homenet>
Björn Steinbrink wrote:
> On 2009.08.13 14:46:07 +0200, Michael Haggerty wrote:
>> (Please note that this technique only works for the typical "tracking
>> upstream" type of rebase; it doesn't help with rebases whose goals are
>> changing the order of commits, moving only part of a branch, rewriting
>> commits, etc.)
>
> Hm, so that pretty much doesn't work at all for creating a clean patch
> series, which usually involves rewriting commits, squasing bug fixes
> into the original commits that introduced the bug etc.
Now that you mention it, there are some other uses of rebase whose
history could be recorded correctly, or at least better, in the DAG. I
am not ready to advocate any of these changes, but I think they are
worth discussing.
A squash of two adjacent commits currently transforms this:
A---B1---B2---C
to this
A---B12---C'
(C' has the same contents and commit message as C but a different
history and therefore a different SHA1.)
But B12 includes both B1 and B2, so the correct history is this:
A---B1---B2----C
\ \ \
---------B12---C'
The fact that B12 has B1 and B2 as ancestors tells git that it
incorporates both of their changes, which correctly describes reality.
Splitting a commit (not really an elementary rebase operation, but
achievable with "edit") transforms this:
A---B12---C
to this:
A---B1---B2---C'
It is not possible to represent this correctly in the DAG, because there
is no way to express that "B1" includes part of "B12" as a parent. But
the following would be more accurate than discarding all history:
A---B12---C
\ \ \
B1---B2---C'
It would of course be difficult for the user-interface layer to be
confident that the changes in B1 and B2 are really equivalent to B12
unless the content of B12 and B2 are identical.
Inserting a new commit into the history (for example as part of
reordering later commits) transforms this:
A---C
to this:
A---B---C'
In this case C' includes everything that is in C, so the correct history is
A---C
\ \
B---C'
However, deleting a commit, which transforms this:
A---B---C
to this:
A---C'
cannot be represented in the DAG, because there is no way to express
that C' includes the changes from C without also implying that it
includes the changes from B.
Rewriting a single commit, under the assumption that the rewritten
commit is the logical equivalent of the original, transforms this:
A---B1---C
to this:
A---B2---C'
where B2 is a hand-rewritten version of B1, and C' is the version of C
produced by the rebase. In this case, the history could be recorded as:
A---B1---C
\ \ \
----B2---C'
but again, it is impossible for the user-interface layer to ascertain
that B2 is equivalent to B1 without help from the user.
All of this extra history would currently create far more clutter than
it is worth, but if there were a way to suppress the display of rebased
commits (as discussed in the third article I quoted), then the extra
information would be there to help git without overwhelming users.
> And even for just continously forward porting a series of commits, a
> common case might be that upstream applied some patches, but not all.
> Can you deal with that?
>
> Example:
>
> A---B---C (upstream)
> \
> H---I---J---K (yours)
>
> Upstream takes some changes:
>
> A---B---C---I'--K'--D (upstream)
> \
> H---I---J---K (yours)
>
> rebase leads to:
>
> A---B---C---I'--K'--D (upstream)
> \
> H'--J' (yours)
>
> What would your approach generate in that case?
There *is no way* to represent this history in a DAG, and therefore the
history of this operation will necessarily be lost. (Well, of course it
could be recorded in metadata supplemental to the DAG, but since the
history would not affect future merges it would be pointless.) The
problem is that there is no way to claim that I' is derived from I
without also implying that I' includes the change in H (which it
doesn't). I discuss this sort of thing in another article [1].
>> For more information, please see the full articles: [...]
>
> In this one you have two DAGs:
> (I fixed the second one to also have the merge commit in "subsystem"
> instead of "topic", so they only differ WRT to the rebased stuff)
>
> A)
> m---N---m---m---m---m---m---M (master)
> \ \
> o---o---O---o---o o'--o'--o'--o'--o'--S (subsystem)
> \ /
> *---*---*-..........-*--T (topic)
>
>
> B)
> m---N---m---m---m---m---m---M (master)
> \ \
> \ o'--o'--o'--o'--o'----------S (subsystem)
> \ / / / / / /
> --------------------o---o---O---o---o---*---*---T (topic)
>
>
> And you say that the former creates problems when you want to merge
> again. How so?
As you very clearly showed (thanks!), the merge problems that I claimed
only occur in some obscure edge cases.
What I *should* have emphasized is that the merge S itself is much more
prone to conflicts in case A) (with merge base N) than in case B) (with
the last "o" as merge base). That is the first advantage of
rebase-with-history.
And please note that I really advocate C), not B):
C)
m---N---m---m---m---m---m---M master
\ \
\ o'--o'--o'--o'--o' subsystem
\ / / / / / \
--------------------o---o---O---o---o \
\ \
\ *'--*'--*' topic
\ / / /
*---*---*
where the topic branch is not merged into the subsystem branch but
rather rebased-with-history. C) has the significant advantage over A)
or B) that the topic branch can be converted to a series of patches (the
*' patches) that apply cleanly to the rebased subsystem branch and can
therefore be submitted upstream. In the case of A) or B), the only
available patch that applies cleanly to the rebased subsystem branch is
S, which is a single commit that squashes together the entire topic
branch and is therefore difficult to review.
So rebasing in a public repository makes it difficult for downstream
developers to apply their work to the rebased branch (because they have
to repeat the conflict resolution that was done in the upstream rebase),
and merging in a topic branch makes it more difficult to create an
easily-reviewable patch series. rebase-with-history has neither of
these problems.
Michael
[1] "Git, Mercurial, and Bazaar—simplicity through inflexibility",
http://softwareswirl.blogspot.com/2009/08/git-mercurial-and-bazaarsimplicity.html
^ permalink raw reply
* Re: [PATCH] Add 'stg prev' and 'stg next'
From: Catalin Marinas @ 2009-08-13 22:30 UTC (permalink / raw)
To: Hannes Eder; +Cc: git
In-Reply-To: <20090807104503.15805.95504.stgit@jazzy.zrh.corp.google.com>
2009/8/7 Hannes Eder <heder@google.com>:
> These commands are related to 'stg top'. They print the patch below
> resp. above the topmost patch, given that they exist.
I applied it. Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Work around performance bug in subprocess.Popen.communicate()
From: Catalin Marinas @ 2009-08-13 22:18 UTC (permalink / raw)
To: Karl Wiberg; +Cc: mandolaerik, git
In-Reply-To: <20090804085125.GB27452@lux.e.vtech>
2009/8/4 Karl Wiberg <kha@virtutech.com>:
> On 2009-07-31 12:27:53 +0100, Catalin Marinas wrote:
>
>> But can this not lead to a deadlock if the __indata is big? The
>> stdout of the created process is only processed once the whole
>> __indata is written. I thought communicate() was created to avoid
>> this issue.
>
> I don't think there's a problem. write() isn't supposed to have a
> limit on the amount of data it will accept in one call, as far as I'm
> aware. Plus, it works just fine with Erik's test case---which in my
> case was about 7 MB. If it can handle 7 MB, I doubt there's a limit
> we'll hit anytime soon.
write() itself doesn't have a limit, it's mainly what the application
receiving the data can handle. In the Git case, I think it takes all
the input as it isn't a filtering tool (things may be different with
tools like sed etc.).
> Oh, and we still call communicate()---we just don't pass it any
> additional bytes to write to stdin.
Yes, but if write() is blocked, communicate() won't be called.
Since we are only using Git, I'll merge this patch (and maybe add a comment).
--
Catalin
^ permalink raw reply
* Re: [PATCH 2/4] fast-import: define a new option command
From: Sverre Rabbelier @ 2009-08-13 22:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Git List, Junio C Hamano
In-Reply-To: <20090813221213.GR1033@spearce.org>
Heya,
On Thu, Aug 13, 2009 at 15:12, Shawn O. Pearce<spearce@spearce.org> wrote:
> No, I don't have a really good reason for the command line overrides
> the file other than this simple rule:
Nice anecdote :P.
> What is this, gang up on Shawn's words-of-wisdom week? Both this
> thread and my intern this week have been argueing with me about
> what seem to me to be fairly trivial things. Maybe I just need to
> take vacation. Good thing I have one coming in 5 weeks.
Didn't you get the memo, you could be crashing an airplane [0] like that ;).
> I say use the version where we store the values (e.g. file names)
> during option parsing, and then actually apply those saved values
> just before the first non-option command. Which I think only has
> an impact on the import-marks option, the rest are all just simple
> variable updates whose values aren't read until after the first
> non-option command anyway.
Ok, that's v3, speaking of which, does it look good enough for inclusion?
[0] http://www.thehackerchickblog.com/2009/05/plane-crashes-software-failures-and.html
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/4] fast-import: define a new option command
From: Shawn O. Pearce @ 2009-08-13 22:12 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Git List, Junio C Hamano
In-Reply-To: <fabb9a1e0908131501o73807f81mb230530c284ad123@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Aug 13, 2009 at 14:51, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > Sorry if I spoil the party, but maybe if things get so complicated, it may
> > be a sign that the original version (stream overrides command line, since
> > it knows better) is to be preferred? ?After all, if hg fast-export says
> > that the marks should be imported from a certain file, it may be for a
> > _very good_ reason...
>
> Yes, and that should Just Work (which it does). Also, I'm not sure how
> often one would output a stream on one computer, then move it to
> another and import it there, but I'll methinks Shawn brought it up for
> a reason ;). However, I do think it's better design to only store the
> name of the import file and then do the actual import later on (to
> prevent double imports).
>
> I don't have a preference either way (both patches are already written
> after all). Shawn?
No, I don't have a really good reason for the command line overrides
the file other than this simple rule:
If the file is likely to be several hundred MiB, or bigger; thou
shall never try to open it with vi, *especially* vi on a Solaris
system, as at least one line is likely to be too long.
If the file header contains paths to other files, it is likely
one will want to modify that header sometime, because you moved
the file between systems.
Given the size of the file above, you can't just fix it with vi.
Lacking a tool that *can* do this edit safely (and Dscho's simple
sed wasn't enough, as I already pointed out, oh and Solaris sed
also fails on long lines), we *should* be able to override this on
the command line, *especially* since we already have the command
line option standardized!
What is this, gang up on Shawn's words-of-wisdom week? Both this
thread and my intern this week have been argueing with me about
what seem to me to be fairly trivial things. Maybe I just need to
take vacation. Good thing I have one coming in 5 weeks.
I say use the version where we store the values (e.g. file names)
during option parsing, and then actually apply those saved values
just before the first non-option command. Which I think only has
an impact on the import-marks option, the rest are all just simple
variable updates whose values aren't read until after the first
non-option command anyway.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/4] fast-import: define a new option command
From: Sverre Rabbelier @ 2009-08-13 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Git List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0908132350190.8306@pacific.mpi-cbg.de>
Heya,
On Thu, Aug 13, 2009 at 14:51, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> Sorry if I spoil the party, but maybe if things get so complicated, it may
> be a sign that the original version (stream overrides command line, since
> it knows better) is to be preferred? After all, if hg fast-export says
> that the marks should be imported from a certain file, it may be for a
> _very good_ reason...
Yes, and that should Just Work (which it does). Also, I'm not sure how
often one would output a stream on one computer, then move it to
another and import it there, but I'll methinks Shawn brought it up for
a reason ;). However, I do think it's better design to only store the
name of the import file and then do the actual import later on (to
prevent double imports).
I don't have a preference either way (both patches are already written
after all). Shawn?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs
From: Jakub Narebski @ 2009-08-13 22:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, Bert Wesarg, Daniel Barkalow, git,
Brian Gernhardt
In-Reply-To: <7vocqkydum.fsf@alter.siamese.dyndns.org>
On Wed, 12 August 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> 1. Is there some other syntax that _doesn't_ have this breakage
>>> but that similarly helps the "vast majority of Git users".
>>
>> Well, proposed possible syntax was:
>> 1. <vcs>:<repository location>
>> ...
>> 2. <vcs>::<repository location>
>> ...
>> 3. <vcs>+<repository location>
>>
>> e.g.
>>
>> svn+http://svn.example.com/project
>>
>> but
>>
>> http+svn://svn.example.com/project
>> svn+path/to/repo
>
> I do not think these are valid examples to demonstrate that 3 is bad.
>
> We do not have (and we will not create) "http+svn://" native transport, so
> the former can only mean "Feed 'svn://svn.example.com/project' to the vcs
> helper whose name is 'http'". Similarly I do not see any way to read the
> latter other than "Feed 'path/to/repo' to 'svn' vcs helper".
And not "Use 'svn+path/to/repo' as local filesystem path to repository?
On the other hand you can always use here './svn+path/to/repo'
> Double-colon (your 2) is also workable. It probably is slightly better
> than plus because it does not have to grandfather "git+ssh" and "ssh+git"
> and that would be beneficial for requiring less complexity in both code
> (i.e. special case logic) and more importantly in mental burden to the end
> users (i.e. '::' would stand out more than '+' and clearly different from
> traditional git URLs in all cases).
>
> As Jeff said (your 1.), a single colon ':' has a rather bad ambiguity
> between <vcs> and hostname part in the existing scp-style repository
> naming.
Also double colon is better for scp-like repository location, as e.g.
svn+example.com:path/to/repo
might be 'path/to/repo' on 'svn+example.com' host; there is no "escape"
mechanism like for './svn+path/to/repo' relative path. On the other
hand unescaped ':' cannot be present in hostname, therefore the following
is unambiguous:
svn::example.com:path/to/repo
But on another hand svn+http://svn.example.com/project/trunk/ looks IMVHO
better that svn::http://svn.example.com/project/trunk/
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: msysGit and SCons: broken?
From: Johannes Schindelin @ 2009-08-13 21:54 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4A846A5A.4000000@dirk.my1.cc>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1062 bytes --]
Hi,
On Thu, 13 Aug 2009, Dirk Süsserott wrote:
> Am 06.08.2009 21:45 schrieb Dirk Süsserott:
> > Am 04.08.2009 00:13 schrieb Johannes Schindelin:
> > > On Mon, 3 Aug 2009, Dirk Süsserott wrote:
> > >
> > > How does your SCons call relate to Git? Do you call it from the Git Bash?
> > > Do you call it from cmd.exe directly? Is Git/bash in your PATH?
> >
> > I used to call SCons from Git-bash and it worked. After Git's upgrade (or
> > some other unknown change) I did the same and it didn't work from Git-bash,
> > but it still worked from cmd.exe. Git-bash ist not in my PATH when I run
> > cmd.exe.
>
> If someone had the same or a similar problem: I tracked it down and
> found a solution. The problem was that I tried to run a Windows program
> from git-bash. The Windows program then faces the bash's $PATH with a
> different separator (':' vs. ';') and a different root directory ('/c/'
> vs. 'C:/').
I cannot believe that. I actually run a Windows program very often, from
Git Bash, and PATH is correctly converted all the time.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Alex Riesen @ 2009-08-13 21:51 UTC (permalink / raw)
To: Luke-Jr; +Cc: Junio C Hamano, Luke Dashjr, git
In-Reply-To: <200908131540.49701.luke@dashjr.org>
On Thu, Aug 13, 2009 at 22:40, Luke-Jr<luke@dashjr.org> wrote:
> On Thursday 13 August 2009 02:36:13 pm Junio C Hamano wrote:
>> Now the obligatory design level question is behind us, let's take a brief
>> look at the codde.
>>
>> > +static int ignore_unmatch = 0;
>>
>> Drop " = 0" and let the language initialize this to zero.
>
> Does C define a default initialisation of zero? My understanding was that
> uninitialised variables are always undefined until explicitly assigned a
> value.
Yes. For statics.
^ permalink raw reply
* Re: GCC Git mirror no longer updating
From: Eric Wong @ 2009-08-13 21:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Bernie Innocenti, Jason Merrill, Daniel Berlin, Frank Ch. Eigler,
git
In-Reply-To: <4aca3dc20908130743g28a32229s194e9caa7a44fa2@mail.gmail.com>
Daniel Berlin <dberlin@dberlin.org> wrote:
> On Wed, Aug 12, 2009 at 11:37 PM, Eric Wong<normalperson@yhbt.net> wrote:
> > Bernie Innocenti <bernie@codewiz.org> wrote:
> >> El Wed, 12-08-2009 a las 09:45 -0400, Jason Merrill escribió:
> >> > On 08/12/2009 06:56 AM, Bernie Innocenti wrote:
> >> > > The git repository format should support concurrent access, but perhaps
> >> > > it only applies to git-receive-pack, not fancy operations such as
> >> > > repacking.
> >> >
> >> > The git repository format, yes, but maybe not the stuff in .git/svn. It
> >> > seems like a temporary index file was referring to an object that got
> >> > garbage collected away. Or maybe the index file was left over from the
> >> > initial import, and not there due to a collision; there don't seem to be
> >> > index files there normally.
> >>
> >> git-svn might be keeping extra information in files that the other git
> >> tools don't know about. This would explain why some objects looked
> >> like orphans and were thus culled. [cc'ing the git list to catch the
> >> attention of the git-svn maintainer(s)].
> >
> > Hi,
> >
> > As far as I can remember, no version of git svn has ever relied on
> > orphanable objects.
> >
> > Of course there are unavoidable race conditions that happen while git
> > svn is running.
> > It is never safe to run repack concurrently while git
> > svn is running (I wouldn't repack/gc simultaneously with _any_ write
> > activity on the repo).
>
> Sounds like you guys need a write lock then for certain operations.
> How do you square this with the auto-repacking the repository does (by
> default i thought it runs git gc every so often).
> We have no control over people pushing branches back at the repo, it
> may be happening when git-svn is running
Actually, I think the prune operation in git gc is the only potentially
unsafe part (and not repack). Double-checking with pruning during gc,
it seems to only expire things older than two weeks by default (when
used with gc).
So I think git svn is safe in the face of repack/gc after all.
Manually running git prune without the --expire argument isn't safe,
but we don't recommend that anyways.
> Where does it say anything about this in the docs so that people know this?
Junio: can you confirm my observations above? I think everything is
safe by default as-is. Thanks
> > git svn itself can/will run "git gc" in-between
> > revisions if needed. You can safely repack manually whenever git svn is
> > not running.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/4] fast-import: define a new option command
From: Johannes Schindelin @ 2009-08-13 21:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, Git List, Junio C Hamano
In-Reply-To: <20090813175211.GQ1033@spearce.org>
Hi,
On Thu, 13 Aug 2009, Shawn O. Pearce wrote:
> Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > On Thu, Aug 13, 2009 at 10:41, Shawn O. Pearce<spearce@spearce.org> wrote:
> > > Uh, no, if we have "option import-marks=..." and we can't find the
> > > file "..." and we have no --import-marks command line flag that
> > > would have overridden it, we need to abort with an error.
> >
> > Ah, then how about in option_import_marks() we only store the name of
> > the file, like in option_export_marks, and at the end, when we reach
> > the first non-option command (and we've parsed argv), we read the
> > file. That way it's only read once, and it deals with the above
> > scenario.
>
> That's better. :-)
Sorry if I spoil the party, but maybe if things get so complicated, it may
be a sign that the original version (stream overrides command line, since
it knows better) is to be preferred? After all, if hg fast-export says
that the marks should be imported from a certain file, it may be for a
_very good_ reason...
Ciao,
Dscho
^ permalink raw reply
* Re: git cherry to find equivalent commit IDs?
From: Avery Pennarun @ 2009-08-13 21:37 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0908131413w1a2efca8t31ac8cc43e1d6888@mail.gmail.com>
On Thu, Aug 13, 2009 at 9:13 PM, <skillzero@gmail.com> wrote:
> For example, commit 3642151 on branch A was a cherry pick of a commit
> 460050c on master:
>
> $ git branch -a --contains 3642151
> A
>
> $ git branch -a --contains 460050c
> * master
>
> $ git cherry -v master 3642151
> - 3642151435ce5737debc1213de46dd556475bfad1 fixed bug
>
> I assume that means an equivalent change to 3642151 is already in
> master (which it is, as commit 460050c). But I want to find out the
> commit ID on master that's equivalent to 3642151 (i.e. something that
> tells me it's 460050c).
git show 3642151 | git patch-id
You should get a line with two hashes; the first is the patchid (call
it PATCHID_FROM_ABOVE)
git log -p | git patch-id | grep PATCHID_FROM_ABOVE
This should give you a list of all commits that correspond to that patchid.
Note that if there were conflicts when applying the patch, the patchid
probably changed.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] block-sha1: more good unaligned memory access candidates
From: Nicolas Pitre @ 2009-08-13 21:28 UTC (permalink / raw)
To: George Spelvin; +Cc: git, gitster, torvalds
In-Reply-To: <20090813201542.25431.qmail@science.horizon.com>
On Thu, 13 Aug 2009, George Spelvin wrote:
> > Wow. Is it now faster than the arm/ and ppc/ hand-tweaked assembly?
>
> It's probably faster than the ARM, which was tuned for size rather
> than speed, but if you want to rework the assembly for speed, the ARM's
> rotate-and-add operations allow tricks which I doubt GCC can pick up on.
> (You have to notice that the F(b,c,d) function is bitwise, so you can
> do it on rotated data and do the rotate when you add the result to e.)
gcc is not too bad at merging ALU and shift/rotate operations into the
same instruction. However, to make a really optimal ARM version, some
custom SHA_ROUND macros with inline assembly could be made. I suspect
that wouldn't gain much though, as the pure shift/rotate mov
instructions really aren't that many in the generated code.
> I'd be surprised if it were faster than PPC code, especially on the
> in-order G3 and G4 cores where careful scheduling really pays off.
> But maybe I just get to be surprised...
Given that PPC has enough register to hold the entire state, it is then
only a matter of proper instruction scheduling which modern gcc ought to
do right. If not then this is a good test case for gcc people to fix
the PPC machine pipeline description.
> For automatic assembly tuning, I was thinking of having a .c file that
> has a bunch of #ifdef __PPC__ statements that gets run through $(CC) -E.
> That should be a fairly portable way to
??
> The other question about unaligned access is whether it's beneficial
> to make the fetch loop work like this:
>
> char const *in;
> uint32_t *out
> unsigned lsb = (unsigned)p & 3;
> uint32_t const *p32 = (uint32_t const *)(in - lsb);
> uint32_t t = ntohl(*p32);
>
> switch (lsb) {
>
> case 0:
> *out++ = t;
> for (i = 1; i < 16; i++)
> *out++ = ntohl(*++p32);
> break;
> case 1:
> for (i = 0; i < 16; i++) {
> uint32_t s = t << 8;
> t = ntohl(*++p32);
> *out++ = s | t >> 24;
> }
> break;
> case 1:
> for (i = 0; i < 16; i++) {
> uint32_t s = t << 16;
> t = ntohl(*++p32);
> *out++ = s | t >> 16;
> }
> break;
> case 1:
> for (i = 0; i < 16; i++) {
> uint32_t s = t << 24;
> t = ntohl(*++p32);
> *out++ = s | t >> 8;
> }
> break;
> }
>
> On the ARM, at least, ntohl() isn't particularly cheap, so loading 4
> bytes and assembling them turns out to be cheaper. But it's a thought.
Well, that would have to be tested. This could possibly only be a gain
if you have a fast ntohl() though.
And the other question is also to decide when this is good enough for a
generic version. Gaining 5% speedup on raw SHA1 throughput with ugly
code might not be worth the maintenance hassle. At that point you might
as well go back to a purely asm version if you really want to get the
extra edge.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/4] fast-import: define a new option command
From: Sverre Rabbelier @ 2009-08-13 21:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, Git List
In-Reply-To: <7vhbwb5tul.fsf@alter.siamese.dyndns.org>
Heya,
On Thu, Aug 13, 2009 at 13:42, Junio C Hamano<gitster@pobox.com> wrote:
> Heh, thanks; it appears I lagged behind by about 2 hours?
So it would seem, not a bad latency at all though.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git cherry to find equivalent commit IDs?
From: skillzero @ 2009-08-13 21:13 UTC (permalink / raw)
To: git
Is there a way to get the commit ID of a patch that was cherry picked
(or via a manually applied patch)? I'm trying to get an equivalent to
git branch --contains, but instead of comparing the commit ID, it
compares patch IDs so it works for cherry picks and manual patches. It
seems like git cherry almost does what I want, but it only seems to
show the commit ID of the commit on the other branch rather than the
branch I specify to git cherry. I may just be using git cherry
incorrectly though.
For example, commit 3642151 on branch A was a cherry pick of a commit
460050c on master:
$ git branch -a --contains 3642151
A
$ git branch -a --contains 460050c
* master
$ git cherry -v master 3642151
- 3642151435ce5737debc1213de46dd556475bfad1 fixed bug
I assume that means an equivalent change to 3642151 is already in
master (which it is, as commit 460050c). But I want to find out the
commit ID on master that's equivalent to 3642151 (i.e. something that
tells me it's 460050c).
I'm basically looking for something like git branch --contains, but
that searches by patch ID so it can find cherry picked or manually
applied patches:
$ git branch -a --contains-equivalent 3642151
* master (via commit 460050c)
A (via commit 3642151)
Is there a way to do that?
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Thomas Rast @ 2009-08-13 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luke Dashjr, git
In-Reply-To: <7vy6pna4lu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> Chould you refresh my memory a bit?
>
> In what circumstance is "rm --ignore-unmatch" useful to begin with?
Not sure about add --ignore-unmatch myself, but there's even an
example of rm --ignore-unmatch in man git-filter-branch, along the
lines of
git filter-branch --index-filter '
rm --ignore-unmach some_file_that_shouldnt_be_in_history
' -- --all
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Document --ignore-unmatch in git-add.txt
From: Luke Dashjr @ 2009-08-13 21:03 UTC (permalink / raw)
To: git; +Cc: Luke Dashjr
In-Reply-To: <7vr5vfa4ha.fsf@alter.siamese.dyndns.org>
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
---
Documentation/git-add.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index e67b7e8..6e30ee9 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -10,7 +10,8 @@ SYNOPSIS
[verse]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
- [--refresh] [--ignore-errors] [--] [<filepattern>...]
+ [--refresh] [--ignore-errors] [--ignore-unmatch] [--]
+ [<filepattern>...]
DESCRIPTION
-----------
@@ -119,6 +120,9 @@ apply.
them, do not abort the operation, but continue adding the
others. The command shall still exit with non-zero status.
+--ignore-unmatch::
+ Exit with a zero status even if no files matched.
+
\--::
This option can be used to separate command-line options from
the list of files, (useful when filenames might be mistaken
--
1.6.3.3
^ permalink raw reply related
* [PATCH] port --ignore-unmatch to "git add"
From: Luke Dashjr @ 2009-08-13 21:02 UTC (permalink / raw)
To: git; +Cc: Luke Dashjr
In-Reply-To: <7vr5vfa4ha.fsf@alter.siamese.dyndns.org>
"git rm" has a --ignore-unmatch option that is also applicable to "git add"
and may be useful for persons wanting to ignore unmatched arguments, but not
all errors.
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
---
builtin-add.c | 27 +++++++++++++++++++--------
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 581a2a1..3882482 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -19,6 +19,7 @@ static const char * const builtin_add_usage[] = {
};
static int patch_interactive, add_interactive, edit_interactive;
static int take_worktree_changes;
+static int ignore_unmatch = 0;
static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
{
@@ -60,13 +61,18 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
*dst++ = entry;
}
dir->nr = dst - dir->entries;
- fill_pathspec_matches(pathspec, seen, specs);
- for (i = 0; i < specs; i++) {
- if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]))
- die("pathspec '%s' did not match any files",
- pathspec[i]);
+ if (!ignore_unmatch)
+ {
+ fill_pathspec_matches(pathspec, seen, specs);
+
+ for (i = 0; i < specs; i++) {
+ if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]))
+ die("pathspec '%s' did not match any files",
+ pathspec[i]);
+ }
}
+
free(seen);
}
@@ -107,9 +113,12 @@ static void refresh(int verbose, const char **pathspec)
seen = xcalloc(specs, 1);
refresh_index(&the_index, verbose ? REFRESH_SAY_CHANGED : REFRESH_QUIET,
pathspec, seen);
- for (i = 0; i < specs; i++) {
- if (!seen[i])
- die("pathspec '%s' did not match any files", pathspec[i]);
+ if (!ignore_unmatch)
+ {
+ for (i = 0; i < specs; i++) {
+ if (!seen[i])
+ die("pathspec '%s' did not match any files", pathspec[i]);
+ }
}
free(seen);
}
@@ -226,6 +235,8 @@ static struct option builtin_add_options[] = {
OPT_BOOLEAN('A', "all", &addremove, "add all, noticing removal of tracked files"),
OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
OPT_BOOLEAN( 0 , "ignore-errors", &ignore_add_errors, "just skip files which cannot be added because of errors"),
+ OPT_BOOLEAN( 0 , "ignore-unmatch", &ignore_unmatch,
+ "exit with a zero status even if nothing matched"),
OPT_END(),
};
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 2/5] fix "git add --ignore-errors" to ignore pathspec errors
From: Luke-Jr @ 2009-08-13 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luke Dashjr, git
In-Reply-To: <7vr5vfa4ha.fsf@alter.siamese.dyndns.org>
On Thursday 13 August 2009 02:38:57 pm Junio C Hamano wrote:
> Luke Dashjr <luke-jr+git@utopios.org> writes:
> > Unmatched files are errors, and should be ignored with the rest of them.
>
> Why is this a "fix"?
>
> I would understand if it were "Make --ignore-errors imply --ignore-unmatch
> unconditionally". But then I do not think I would necessarily agree it is
> a good change.
>
> The user may know that some files in the work tree are unreadable and
> cannot be indexed (hence he gives --ignore-errors) but he still may want
> to catch a typo on the command line.
>
> I do not think it is wise to make --ignore-errors imply --ignore-unmatch
> unconditionally like this patch does without any escape hatch.
Are unmatched files not errors? Perhaps the old flag should be renamed to
--ignore-read-errors and a new --ignore-errors that implies both added. Or
maybe just a documentation change to preserve compatibility with anything that
might assume that...
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Luke-Jr @ 2009-08-13 20:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luke Dashjr, git
In-Reply-To: <7vy6pna4lu.fsf@alter.siamese.dyndns.org>
On Thursday 13 August 2009 02:36:13 pm Junio C Hamano wrote:
> Luke Dashjr <luke-jr+git@utopios.org> writes:
> > "git rm" has a --ignore-unmatch option that is also applicable to "git
> > add" and may be useful for persons wanting to ignore unmatched arguments,
> > but not all errors.
>
> Chould you refresh my memory a bit?
>
> In what circumstance is "rm --ignore-unmatch" useful to begin with?
> A similar question for "add --ignore-unmatch".
Not sure on its purpose for "rm", but for "add"...
Avoiding a race condition in automation. In particular, if the file is deleted
between the time the argument list is built until git scans for matches.
> Now the obligatory design level question is behind us, let's take a brief
> look at the codde.
>
> > +static int ignore_unmatch = 0;
>
> Drop " = 0" and let the language initialize this to zero.
Does C define a default initialisation of zero? My understanding was that
uninitialised variables are always undefined until explicitly assigned a
value.
> > static void fill_pathspec_matches(const char **pathspec, char *seen, int
> > specs) {
> > @@ -63,7 +64,7 @@ static void prune_directory(struct dir_struct *dir,
> > const char **pathspec, int p fill_pathspec_matches(pathspec, seen,
> > specs);
> >
> > for (i = 0; i < specs; i++) {
> > - if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]))
> > + if (!seen[i] && pathspec[i][0] && !file_exists(pathspec[i]) &&
> > !ignore_unmatch) die("pathspec '%s' did not match any files",
> > pathspec[i]);
> > }
> > @@ -108,7 +109,7 @@ static void refresh(int verbose, const char
> > **pathspec) refresh_index(&the_index, verbose ? REFRESH_SAY_CHANGED :
> > REFRESH_QUIET, pathspec, seen);
> > for (i = 0; i < specs; i++) {
> > - if (!seen[i])
> > + if (!seen[i] && !ignore_unmatch)
> > die("pathspec '%s' did not match any files", pathspec[i]);
> > }
> > free(seen);
>
> What's the point of these two loops if under ignore_unmatch everything
> becomes no-op?
>
> That is, wouldn't it be much more clear if you wrote like this?
I'm not overly familiar with the git codebase, but wouldn't a null 'seen'
variable break the refresh_index call? The loops themselves can be avoided, I
suppose. I'll submit a new patch to optimise the changes (and rebase)...
^ permalink raw reply
* Re: [PATCH 2/4] fast-import: define a new option command
From: Junio C Hamano @ 2009-08-13 20:42 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List
In-Reply-To: <fabb9a1e0908131301g4361a06es98fbf3c256c25300@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Thu, Aug 13, 2009 at 12:26, Junio C Hamano<gitster@pobox.com> wrote:
>> How about making the option parser get and keep the _name_ of the file
>> until option parsing session (i.e. read the stream until initial run of
>> "option" command runs out and then parse the command line to override),
>> and then finally open the file and read it?
>
> On Thu, Aug 13, 2009 at 10:44, Sverre Rabbelier<srabbelier@gmail.com> wrote:
>> Ah, then how about in option_import_marks() we only store the name of
>> the file, like in option_export_marks, and at the end, when we reach
>> the first non-option command (and we've parsed argv), we read the
>> file. That way it's only read once, and it deals with the above
>> scenario.
>
> Which is exactly what the latest version does :).
Heh, thanks; it appears I lagged behind by about 2 hours?
^ permalink raw reply
* Re: rebase-with-history -- a technique for rebasing without trashing your repo history
From: Abderrahim Kitouni @ 2009-08-13 20:31 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Bazaar, mercurial mailing list, Git Mailing List
In-Reply-To: <4A840B0F.9060003@alum.mit.edu>
2009/8/13 Michael Haggerty <mhagger@alum.mit.edu>:
> I've been thinking a lot about the problems of tracking upstream changes
> while developing a feature branch.
Isn't this the purpose of pbranch [1] (and I beleive bzr's loom[2] and
git's topgit[3])?
Peace,
Abderrahim
[1] http://arrenbrecht.ch/mercurial/pbranch/
[2] https://launchpad.net/bzr-loom
[3]http://repo.or.cz/w/topgit.git
^ permalink raw reply
* merging individual files
From: Chris Marshall @ 2009-08-13 20:16 UTC (permalink / raw)
To: git
Suppose that merging branch dev1 into master would result in three files, f1,
f2, and f3 being changed, and that I only want to merge the changes for f1 and
f2 and not the changes for f3 currently. Later on, I want to accept the f3
changes. Suppose further that the changes to f1, f2, and f3 occurred in a
single commit to branch dev1.
What is the simplest way to use git to achieve that effect?
More generally, I need a way to accept the changes for one or two files while
rejecting the changes for a potentially large number of files, then later on
accepting the changes for the large number of files.
I work at a company where perforce is currently used for all development and am
trying to work out the git equivalents to all of the perforce flows we use.
This workflow is the only one that I am stumped on.
One solution that occurs to me is to create a temporary branch off of the (most
recent) common ancestor of master and br1, let's say br2, checkout the files
from br1 that I want to merge into master and commit those to br2, then merge
br2 into master:
git checkout common_ancestor_commit
git checkout -b br2
git checkout br1 f1 f2
git commit
git checkout master
git merge br2
git branch -d br2
This strikes me as not too bad of a procedure, as long as there is a graceful
way of determining the most recent common ancestor of br1 and master. What's
the simplest way of doing that?
^ permalink raw reply
* Re: [PATCH] block-sha1: more good unaligned memory access candidates
From: George Spelvin @ 2009-08-13 20:15 UTC (permalink / raw)
To: git, gitster; +Cc: linux, nico, torvalds
> Wow. Is it now faster than the arm/ and ppc/ hand-tweaked assembly?
It's probably faster than the ARM, which was tuned for size rather
than speed, but if you want to rework the assembly for speed, the ARM's
rotate-and-add operations allow tricks which I doubt GCC can pick up on.
(You have to notice that the F(b,c,d) function is bitwise, so you can
do it on rotated data and do the rotate when you add the result to e.)
I'd be surprised if it were faster than PPC code, especially on the
in-order G3 and G4 cores where careful scheduling really pays off.
But maybe I just get to be surprised...
For automatic assembly tuning, I was thinking of having a .c file that
has a bunch of #ifdef __PPC__ statements that gets run through $(CC) -E.
That should be a fairly portable way to
The other question about unaligned access is whether it's beneficial
to make the fetch loop work like this:
char const *in;
uint32_t *out
unsigned lsb = (unsigned)p & 3;
uint32_t const *p32 = (uint32_t const *)(in - lsb);
uint32_t t = ntohl(*p32);
switch (lsb) {
case 0:
*out++ = t;
for (i = 1; i < 16; i++)
*out++ = ntohl(*++p32);
break;
case 1:
for (i = 0; i < 16; i++) {
uint32_t s = t << 8;
t = ntohl(*++p32);
*out++ = s | t >> 24;
}
break;
case 1:
for (i = 0; i < 16; i++) {
uint32_t s = t << 16;
t = ntohl(*++p32);
*out++ = s | t >> 16;
}
break;
case 1:
for (i = 0; i < 16; i++) {
uint32_t s = t << 24;
t = ntohl(*++p32);
*out++ = s | t >> 8;
}
break;
}
On the ARM, at least, ntohl() isn't particularly cheap, so loading 4
bytes and assembling them turns out to be cheaper. But it's a thought.
^ permalink raw reply
* Re: [PATCH] block-sha1: more good unaligned memory access candidates
From: Nicolas Pitre @ 2009-08-13 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v63crbja2.fsf@alter.siamese.dyndns.org>
On Thu, 13 Aug 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > As it is now, I was about to suggest:
> >
> > git mv block-sha1/sha1.[ch] .
> > rmdir block-sha1
> > rm -r mozilla-sha1
> > rm -r arm
> > rm -r ppc
> >
> > and remove support for openssl's SHA1 usage, making this implementation
> > unconditional. After all it is faster, or so close to be faster than
> > the alternatives, that we should probably cut on the extra dependency
> > and simplify portability issues at the same time.
>
> Wow. Is it now faster than the arm/ and ppc/ hand-tweaked assembly?
It is indeed faster than the ARM assembly version by far, and faster
than all the alternative implementations too, but with a 7x increase in
compiled code size. In the context of Git I think this is a good
compromize. Making the assembly version faster than the C version could
be possible, but that would require quite some work and I don't expect
the gain to be significant, certainly not worth the trouble.
Furthermore the C version can be used to generate ARM Thumb code while
the asm version cannot without yet more work.
Nicolas
^ 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