* [RFC] Importing from a patch-oriented SCM
From: Martin Langhoff @ 2005-08-19 7:04 UTC (permalink / raw)
To: GIT
I am drafting an import script to turn a GNU Arch into a GIT archive.
Importing the branches and commits increamentally is reasonably
straightforward -- or so it seems so far. Note: the repository
manipulation is based on cvsimport -- so my knowledge of the git repo
internals is still pertty close to zero.
Each patchset has a unique identifier, and can carry metadata with the
identifiers of the patches it "includes". If you are using gnu arch,
when you merge across branches, it'll know to skip a particular
patchset if it has been applied already. AFAICT there is no such
concept in GIT, and I wonder what to do with all this metadata about
merges.
My proto-plan is to keep track of merged stuff (in a cache file
somewhere), and if a particular merge means that the branches are
fully merged up to the last patch of the series (if no commits from
the source branch have been skipped) mark it as a merge in GIT.
If the merges have been done out-of-order, that may show up in the
latest merge. For example, branch A and B of the same project each
have 10 commits from the branching point. If a merge A -> B does
commits 1,2,3,7,8 it gets imported to git as a merge up to commit "3",
although there is more there. The next merge, which does 4,5,6,10 will
show up as a merge of commit 8.
Yuk.
If I remember correctly, Junio added some stuff in the merge & rebase
code that will identify if a particular patch has been seen and
applied, and skip it even if it's a bit out of order. But I don't know
what that is based on, and whether I can somehow maximize the chances
of the patch being identified as already merged across branches. If
it's based on the initial commit identifier being carried through
(does that travel with commits when you merge?) I stand a small
chance. Otherwise, I'm lost.
Suggestions?
cheers,
martin
^ permalink raw reply
* [PATCH] Fixup Documentation Makefile for cg-%.txt
From: Kris Shannon @ 2005-08-19 7:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
The syntax for .PRECIOUS in a makefile requires
an implicit target to match exactly:
%.txt does not cover all *.txt
Signed-off-by: Kris Shannon <kris.shannon@gmail.com>
---
Documentation/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -52,7 +52,7 @@
clean:
rm -f *.xml *.html *.1 *.7 cg-*.txt cogito.txt
-.PRECIOUS: %.txt
+.PRECIOUS: cg-%.txt
introduction.html: ../README
asciidoc -b xhtml11 -d article -f asciidoc.conf -o $@ $<
^ permalink raw reply
* Multi-head fetches, pulls, and a King Ghidorah
From: Junio C Hamano @ 2005-08-19 7:45 UTC (permalink / raw)
To: git
The current "pu" branch has most of the necessary plumbing for
multi-head fetching, pulling and creating Octopus merges based
on multiple heads. I have made "git pull" multi-head aware but
did not make it multi-head capable.
I have been trying out Tony Luck's excellent topic-branch
workflow (see Documentation/using-topic-branches.txt), and the
head of the "pu" branch is an Octopus on top of the "master" and
my two private topic branches [*1*] made with "git octopus".
I have been thinking about how the multi-head fetch and merge
should interact with each other. It appears to me that coming
up with a reasonably semantics for "git pull" that would fit
everybody is very difficult, because there are at least two
different valid workflows that involve multi-head pulling, and
they need to do different things. I'll talk about "git pull"
that can deal with more than one remote heads, which does not
exist yet, in the next couple of paragraphs.
Suppose I were the Emperor Penguin [*2*], and Jeff asks "Please
pull from my netdev-2.6.git repository, sis190 and e100
branches." It is very reasonable to expect the following to
fetch heads of those two branches and attempt to make an Octopus
[*3*] on top of a copy of the Penguin head:
$ cat .git/branches/jgarzik
kernel.org:/pub/linux/kernel/git/jgarzik/
$ git checkout -b try-jeffs-update master
$ git pull jgarzik/netdev-2.6.git/ sis190 e100
$ git diff -p master..HEAD | git apply --stat --summary
The arguments to pull, especially the refspec parameters
("sis190" and "e100" in the above example) are given to the
underlying "git fetch", and because neither of them have a
colon, they are not stored in corresponding places under the
local refs/heads/. Instead, fetched heads would be fed directly
to "git octopus" inside "git pull" (just like the current "git
pull" invokes "git resolve" internally after fetching just one
head).
However, suppose then I were Joe Random, an individual netdev
contributor who is interested in these two netdev branches.
Upon seeing the pull request, I might decide it is a good time
to get changes from there, my upstream.
$ git pull jgarzik/netdev-2.6.git/ sis190:sis190 e100:e100
Because I am keeping track of copies of these two branches, I
use "sis190:sis190 e100:e100" to update my local heads.
I might have some local changes in these two branches. The old
"git fetch" unconditionally overwrote local heads when told to,
but lately it acquired the "reverse push" semantics Johannes
Schindelin proposed to make it safer. The fetch process only
overwrites local heads when the upstream change results in a
fast-forward merge; practically, that happens only when I have
not worked on that branch since I pulled from the upstream the
last time. So my refs/heads/sis190 and refs/heads/e100 may be
copies of Jeff's heads, or they may be the same heads as I had
before starting the fetch.
At this point, it might be reasonable to expect that the above
"git pull" command would behave as if I pulled (i.e. fetched and
merged) these heads separately, using traditional single-head
pull:
$ git checkout sis190
$ git pull jgarzik/netdev-2.6.git/ sis190:sis190
$ git checkout e100
$ git pull jgarzik/netdev-2.6.git/ e100:e100
That is, fetch and resolve them independently and individually.
Back in the Emperor Penguin example, he _could_ also have been
interested in keeping copies of Jeff's branch heads, so he could
have written refspecs on the command line the same way as Joe
Random did. I.e. instead of:
$ git pull jgarzik/netdev-2.6.git/ sis190 e100
he could have said:
$ git pull jgarzik/netdev-2.6.git/ sis190:sis190 e100:e100
Both "Octopus" and "Multiple independent pull" semantics are
valid to support different workflows, and there is no way to
differenciate the two from the command line, without giving an
extra flag and making the implementation more complicated.
Currently, I am inclined to leave the current "not more than one
remote head" implementation, and possibly extend it to support
the "Octopus" semantics later, for three very simple reasons.
(1) What the latter "git pull" is buying us compared to two
traditional single-head pulls is very little; that the
underlying "git fetch" _could_ obtain packs more
efficiently than two independent fetches.
(2) The netdev example happened to involve multiple heads from
a single repository, but the pull request could as well
have been "jgarzik/netdev-2.6.git#sis190 and
jgarzik/libata-dev.git#sil24", in which case I wouldn't
have to be worrying about multi-head pull at all; the user
would just have used two independent traditional "git
pull" --- there is no other option.
(3) Or course, because I am lazy ;-). Seriously, multiple
independent merges is a nightmere when you start thinking
about what to do when you get a conflict and need to have
the user hand merge in the middle of the first one.
Since "git pull" tentatively would not do multi-head natively,
the Emperor Penguin example needs to be done this way:
$ git checkout -b try-jeffs-update master
$ git fetch jgarzik/netdev-2.6.git/ sis190 e100
$ git octopus
$ git diff -p master..HEAD | git apply --stat --summary
I think this should already work with the current "pu" branch
head.
[Footnotes]
*1* I should probably write a bit about how I do things in a
separate message as a how-to.
*2* I am not a penguin. Figuring out what kind of animal I am
is left as an easter-egg hunt. I have had the answer somewhere
in the current git.git archive for some time ;-).
*3* This one has only three heads, so that would be a Tripus,
but what X-pus counts is not heads but legs, so we should really
be calling this a King Ghidorah who has three heads.
*4* What's currently in "pu" branch dies when a head cannot be
fast forwarded, but I think that is simply a thinko. It should
just refuse to fast-forward and warn, leave the obtained remote
head somewhere other tools can find later, just as the original
"reverse push" script by Johannes did.
^ permalink raw reply
* Re: [RFC] Importing from a patch-oriented SCM
From: Junio C Hamano @ 2005-08-19 7:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f9050819000417ed436e@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> If I remember correctly, Junio added some stuff in the merge & rebase
> code that will identify if a particular patch has been seen and
> applied, and skip it even if it's a bit out of order. But I don't know
I think you are talking about git-patch-id.
f97672225b3b1a2ca57cfc16f49239bed1efcd87
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Jun 23 15:06:04 2005 -0700
Add "git-patch-id" program to generate patch ID's.
A "patch ID" is nothing but a SHA1 of the diff associated
with a patch, with whitespace and line numbers ignored. As
such, it's "reasonably stable", but at the same time also
reasonably unique, ie two patches that have the same "patch
ID" are almost guaranteed to be the same thing.
IOW, you can use this thing to look for likely duplicate
commits.
^ permalink raw reply
* Fix git-mailinfo to understand empty commit messages
From: Marco Costalba @ 2005-08-19 7:59 UTC (permalink / raw)
To: junkio; +Cc: git
In case of empty messages git-mailinfo ignores the "---"
line adding dirty stuff in commit message otherwise empty
Signed-off-by: Marco Costalba <mcostalba@yahoo.it>
---
tools/mailinfo.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
1ebfddf05e4655811157028091d03dfce39cc4f0
diff --git a/tools/mailinfo.c b/tools/mailinfo.c
--- a/tools/mailinfo.c
+++ b/tools/mailinfo.c
@@ -273,6 +273,12 @@ int main(int argc, char ** argv)
}
while (1) {
int len = read_one_header_line(line, sizeof(line), stdin);
+ /* Check for empty messages */
+ if (!memcmp("---", line, 3)) {
+ line[len] = '\n';
+ handle_rest();
+ break;
+ }
if (!len) {
handle_body();
break;
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH/RFC] Allow file removal when "git commit --all" is used.
From: Johannes Schindelin @ 2005-08-19 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll2yenyv.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 18 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> The patch is for people who thinks the user who uses the "--all"
> >> flag deserves the danger that comes with the convenience.
> >>
> >> Comments?
> >
> > This is a sane default behaviour. Maybe introduce yet another flag
> > "--no-remove", which says that removes should not be performed? But then,
> > "--all" is mostly used by lazy people, who probably expect the removes to
> > take place.
>
> Well, let's refrain from using that word; I am one of the "lazy"
> people, but I do that on purpose and from principle, not from
> lazyness. http://members.cox.net/junkio/per-file-commit.txt.
Sorry, when I say "lazy people" I mean "yours truly".
Ciao,
Dscho
^ permalink raw reply
* Re: Merge conflicts as .rej .orig files
From: Catalin Marinas @ 2005-08-19 8:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f9050818200625d64a12@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> After using arch for a while, I've gotten used to getting .rej and
> .orig files instead of big ugly conflict markers inside the file.
> Emacs has a nice 'diff' mode that is a boon when dealing with
> conflicts this way.
>
> Is there a way to convince cogito/git to leave reject files around?
> What utility is git using to do the merges? Or at least: where should
> I look?
You could have a look at StGIT as well. The tool you use for merges is
configurable via the stgitrc file (diff3 is used by default, which
leaves markers in the file). StGIT also leaves the 3 files involved in
the tree-way merge as <file>.{older,local,remote} for further
inspection.
If you prefer other tool than diff3, you can define it in the stgitrc
file. Two examples are given for emacs and xxdiff. You could also
write a small script which invokes diff3 by default and, if it fails,
run the emacs ediff-merge-files-with-ancestor function.
--
Catalin
^ permalink raw reply
* Re: [RFC] Importing from a patch-oriented SCM
From: Johannes Schindelin @ 2005-08-19 8:29 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f9050819000417ed436e@mail.gmail.com>
Hi,
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> Each patchset has a unique identifier, and can carry metadata with the
> identifiers of the patches it "includes". If you are using gnu arch,
> when you merge across branches, it'll know to skip a particular
> patchset if it has been applied already. AFAICT there is no such
> concept in GIT, and I wonder what to do with all this metadata about
> merges.
You should include the metadata in the commit object. If the information
is about parents, they should be parents in git, too. If the information
is something else, you should convert it to readable text and put it in
the comment part of the commit object.
> If I remember correctly, Junio added some stuff in the merge & rebase
> code that will identify if a particular patch has been seen and
> applied, and skip it even if it's a bit out of order.
The usual way of git is to use a 3-way merge: given a common ancestor, try
to apply the changes between the ancestor and the second branch to the
first branch. And yes, this does not take history into account.
Originally, I wanted to write an "intelligent" merge, which turns the
history into patches and tries to merge these, but ultimately I got
convinced that this is too complicated to be worthwhile.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Importing from a patch-oriented SCM
From: Martin Langhoff @ 2005-08-19 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslx61i3s.fsf@assigned-by-dhcp.cox.net>
On 8/19/05, Junio C Hamano <junkio@cox.net> wrote:
> Martin Langhoff <martin.langhoff@gmail.com> writes:
>
> > If I remember correctly, Junio added some stuff in the merge & rebase
> > code that will identify if a particular patch has been seen and
> > applied, and skip it even if it's a bit out of order. But I don't know
>
> I think you are talking about git-patch-id.
Is this used at commit time, and stored somewhere (doesn't seem to be)
or do you select older patches from the destination branch at merge
time?
If you only compare patches since the last merge, patches that were
merged but somehow unreported will fall into a black hole and cause a
conflict going forward anyway. Hmm. That seems to be a problem I
won't be able to avoid if merges happen out-of-order.
I'll try and work out how it's being used during the merge
(pointers/hints welcome) and see if I can do something smart w it.
Thanks!
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Spell __attribute__ correctly in cache.h.
From: Junio C Hamano @ 2005-08-19 9:04 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <812.1124424608@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@cs.berkeley.edu> writes:
> Sun's cc doesn't know __attribute__.
It turns out that your patch breaks GCC build (#ifndef
__attribute__ is true there, and it should be---what it does
cannot be done in preprocessor alone). I am going to work it
around like this. Could you try it with Sun cc please?
---
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -38,11 +38,10 @@
#define NORETURN __attribute__((__noreturn__))
#else
#define NORETURN
-#endif
-
#ifndef __attribute__
#define __attribute__(x)
#endif
+#endif
/*
* Intensive research over the course of many years has shown that
^ permalink raw reply
* Re: Multi-head fetches, pulls, and a King Ghidorah
From: Johannes Schindelin @ 2005-08-19 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy86y1ibg.fsf@assigned-by-dhcp.cox.net>
Hi,
If I understand correctly, the multi-head fetch would not write any ref if
used like this:
git fetch remote:repository/ head tail
but it would try a fast-forward when used like this:
git fetch remote:repository/ head:head tail:tail
Correct? If yes: This is fantastic! It obsoletes my dumb script.
On Fri, 19 Aug 2005, Junio C Hamano wrote:
> However, suppose then I were Joe Random, an individual netdev
> contributor who is interested in these two netdev branches.
> Upon seeing the pull request, I might decide it is a good time
> to get changes from there, my upstream.
>
> $ git pull jgarzik/netdev-2.6.git/ sis190:sis190 e100:e100
>
> Because I am keeping track of copies of these two branches, I
> use "sis190:sis190 e100:e100" to update my local heads.
I propose a "--separate" flag to git pull. This would do exactly the same
as a plain git pull, but for each fetched branch which could not be
fast-forwarded
- try to switch to the branch (dying if it is not the current,
and the working tree is dirty)
- try a merge
- if the merge fails, reset the branch to original state,
write out a temporary head and output a warning
After that, it would switch back to the original branch and check that
out.
For all failed merges, the user needs to "git resolve" (the exact command
line could be output by "git pull --separate").
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Catalin Marinas @ 2005-08-19 9:53 UTC (permalink / raw)
To: Jan Veldeman; +Cc: git
In-Reply-To: <20050818195753.GA9066@fanta>
Jan Veldeman <jan.veldeman@gmail.com> wrote:
> I like stgit very much, but I feel there is still something missing:
> stgit is very handy when you use it for patches which should be pushed to
> mainline rather quickly. But for pacthes which won't be pushed immediately
> to mainline, it would be usefull to have a history of the patches
> itself.
The patch history feature was available in StGIT 0.1/0.2 releases
where you should have run a 'stg commit' before 'stg refresh'. The
commit was handling all the history changes, with separate commit
messages and refresh was updating the main commit with 2 parents. I
removed it in 0.3 after some people (I think it was Paul Jackson and
Daniel Barkalow) convinced me that this would make it yet another SCM
interface on top of GIT, which wasn't really my intention.
The main problem with having multiple parents for a commit object
corresponding to a patch is the upstream merging via 'git pull'. In
general you don't want a gatekeeper to pull the history of your patch
but the patch only.
> The patch below, together with the following script could be used to
> make snapshots of the patch stack (I call it freeze, as I thought snapshot
> was already going to be used for something else):
'snapshot' is not yet used for anything and I'm not sure how it is
best to be implemented. I thought about simply saving the current HEAD
into some .git/refs/heads/<file>, without preserving any history for
the patch. A gitk on this file would show the patches as they were on
the time of the snapshot creation. A new snapshot would remove this.
It might be best for a per-patch history to have a separate file in
<branch>/<patch>/, maybe called freeze, which keeps this history
information. The top one should remain unchanged. Its hash could be
accessed with the 'stg id /freeze' command (implemented
yesterday). This file would only be updated via the 'freeze' command
and its parent would be the previous freeze value.
Would this be close to what you need?
--
Catalin
^ permalink raw reply
* SVN import
From: Matthias Urlichs @ 2005-08-19 10:00 UTC (permalink / raw)
To: git
Quick note: I'm working on importing from SVN.
My current main problem is that SVN's Perl interface leaks server
connections (apparently nobody has used it for any real work yet),
which is of course *bad*, and kindof prevents me from finishing
the job today. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
I could certainly run a marvellous university here if only we didn't
have to have all these damn students underfoot all the time.
-- Terry Pratchett (Hogfather)
^ permalink raw reply
* Re: Multi-head fetches, pulls, and a King Ghidorah
From: Junio C Hamano @ 2005-08-19 10:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508191039460.11916@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> If I understand correctly, the multi-head fetch would not write any ref if
> used like this:
>
> git fetch remote:repository/ head tail
>
> but it would try a fast-forward when used like this:
>
> git fetch remote:repository/ head:head tail:tail
>
> Correct? If yes: This is fantastic! It obsoletes my dumb script.
That is the intent, but what is currently in "pu" is somewhat
broken.
^ permalink raw reply
* Re: [PATCH] Spell __attribute__ correctly in cache.h.
From: Jason Riedy @ 2005-08-19 14:58 UTC (permalink / raw)
To: git
In-Reply-To: <7vk6ii1emh.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- It turns out that your patch breaks GCC build
Whoops, sorry. Your fix works with Sun's cc.
BTW, how would people feel about replacing the
setenv() and unsetenv() calls with the older putenv()?
The Solaris version I have to work on doesn't have
the nicer functions (and I'm not an admin). I have
to check that the unsetenv() in git-fsck-cache.c works
correctly as a putenv before I send along a patch.
There's also the issue that /bin/sh isn't bash, but an
installation-time helper script can fix that.
Jason
^ permalink raw reply
* Re: Questions on 'cvs migration guide''
From: Linus Torvalds @ 2005-08-19 15:18 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f9050818225865deb7ee@mail.gmail.com>
On Fri, 19 Aug 2005, Martin Langhoff wrote:
>
> I'm keen on keeping my 'merge & publish' step in a single repo that
> has all the 'team' branches. The person running this repo will
> probably actually code in separate repos, and merge in there too.
I would suggest against a person owning a "merge and publish". Instead,
just have a public repo that everybody involved to can push to - _they_
will need to merge before they push (since a push won't accept a unrelated
parent), but that way anybody can export their changes at any time,
exactly like with a central CVS repository.
> Right now I'm switching 'heads' (I'm getting used to cogito's use of
> 'branch' for 'remote head') using this quick'n'dirty bit of shell:
No, just do
git checkout <headname>
> but I want to prevent the action if the checkout is 'dirty'. Is there
> any way to check whether cg-diff thinks anything has changed?
If you use "git checkout" to switch branches, it will do that testing for
you. You can still _force_ a head switch with "git checkout -f".
Oh, and if a file was dirty that is the same in both heads, the
"dirtyness" follows you into the new head. If that isn't what you want,
then you need to add some logic like
if [ "$(git-diff-files)" != "" ]; then
echo "Current branch not clean" >&2
exit 1
fi
git checkout "$@"
or something.
Linus
^ permalink raw reply
* FYI: My experiences with cygwin & git
From: Johannes Schindelin @ 2005-08-19 15:23 UTC (permalink / raw)
To: git
Hi,
I tried to compile & run git on cygwin. Two showstoppers:
- cygwin does not support IPv6 (yet). Therefore, it does
not have getaddrinfo() and friends. (minor showstopper)
- fork() and mmap() together have problems. This manifests
itself in "git-diff-tree -p" not working. (showbomber)
No big problem for me, I only tested cygwin out of curiosity.
Ciao,
Dscho
^ permalink raw reply
* Re: Merge conflicts as .rej .orig files
From: Daniel Barkalow @ 2005-08-19 15:30 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f9050818200625d64a12@mail.gmail.com>
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> After using arch for a while, I've gotten used to getting .rej and
> .orig files instead of big ugly conflict markers inside the file.
> Emacs has a nice 'diff' mode that is a boon when dealing with
> conflicts this way.
>
> Is there a way to convince cogito/git to leave reject files around?
> What utility is git using to do the merges? Or at least: where should
> I look?
I believe you should be able to get that effect by having a version
of "git-merge-one-script" that does "diff -c $2 $3 | patch $1" or "diff -c
$2 $1 | patch $3", depending on which you want as the orig. (Or something
like that. I'm not sure exactly how to get the conflict files out of the
script and into the right place, or the arguments it gets.)
Of course, you'll probably have more conflicts to deal with, because the
merging code gets less information that way. (In particular, you'll lose
the "already contains changes" behavior, so you'll be unhappy if you have
patches merged upstream.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Importing from a patch-oriented SCM
From: Daniel Barkalow @ 2005-08-19 16:22 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f905081901521296c24@mail.gmail.com>
On Fri, 19 Aug 2005, Martin Langhoff wrote:
> On 8/19/05, Junio C Hamano <junkio@cox.net> wrote:
> > Martin Langhoff <martin.langhoff@gmail.com> writes:
> >
> > > If I remember correctly, Junio added some stuff in the merge & rebase
> > > code that will identify if a particular patch has been seen and
> > > applied, and skip it even if it's a bit out of order. But I don't know
> >
> > I think you are talking about git-patch-id.
>
> Is this used at commit time, and stored somewhere (doesn't seem to be)
> or do you select older patches from the destination branch at merge
> time?
If a patch is applied verbatim, or a merge results in no conflicts (i.e.,
only offsets), then you can run git-patch-id on the diff caused by it and
compare the result with the git-patch-id of the diff caused by your local
change to see if you've found it. Of course, if there was any modification
to the patch or a conflict was resolved, you won't see a match, but that's
plausibly correct anyway: you don't know whether the content change that
resulted from your patch really matched the change you wanted to make.
> If you only compare patches since the last merge, patches that were
> merged but somehow unreported will fall into a black hole and cause a
> conflict going forward anyway. Hmm. That seems to be a problem I
> won't be able to avoid if merges happen out-of-order.
They might cause conflicts, but they're relatively unlikely to require
manual intervention, because the merging mechanism in git is stronger than
the one in arch (by virtue of identifying a common ancestor), and will
recognize when a section of changes made by both sides is the same and
produce a warning rather than a conflict. That's how the rebase stuff can
identify that your rebased patch is empty (when upstream applies your
patch): the content change that it would make has been made.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git commit (or git-commit-script) question
From: Johnny Stenback @ 2005-08-19 17:06 UTC (permalink / raw)
To: git
Hey all,
git-commit-script --help says:
git commit [-a] [-m <message>] [-F <logfile>] [(-C|-c) <commit>]
[<path>...]
That made me assume that if I do:
git-commit-script somedir
it would *only* commit the changes I've made in "somedir", but it
appears to commit *all* files that have changed (and shows all files in
the list of changed files in the commit message it displays in the
editor), as if it's completely ignoring the <path> argument.
Known problem? I got this using git that I pulled from kernel.org
earlier this morning.
--
jst
^ permalink raw reply
* Re: git commit (or git-commit-script) question
From: Linus Torvalds @ 2005-08-19 17:36 UTC (permalink / raw)
To: Johnny Stenback; +Cc: git
In-Reply-To: <4306119C.8000600@jstenback.com>
On Fri, 19 Aug 2005, Johnny Stenback wrote:
>
> That made me assume that if I do:
>
> git-commit-script somedir
>
> it would *only* commit the changes I've made in "somedir", but it
> appears to commit *all* files that have changed (and shows all files in
> the list of changed files in the commit message it displays in the
> editor), as if it's completely ignoring the <path> argument.
>
> Known problem? I got this using git that I pulled from kernel.org
> earlier this morning.
It works for me. You _should_ see something like
#
# Updated but not checked in:
# (will commit)
#
# modified: somedir/somefile
#
#
# Changed but not updated:
# (use git-update-cache to mark for commit)
#
# modified: otherdir/anotherfile
#
which basically means that it will commit "somedir/somefile", but _not_
commit "otherdir/anotherfile".
However, one thing to look out for is that if you've marked any files for
update (with git-update-cache) those will always be committed regardless
of what arguments you give to "git commit". You can reset the index with
"git reset" if you decided that you don't want to commit after all.
(For example, if you do a "git commit --all", but decide not to commit
after all by writing an empty commit message, that will already have
marked all the files to be committed, so next time, even if you then use
"git commit somedir", all the files in all the _other_ dirs have already
been marked for update, so you'll see everything being committed).
Linus
^ permalink raw reply
* Re: git commit (or git-commit-script) question
From: Johnny Stenback @ 2005-08-19 17:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508191028190.3412@g5.osdl.org>
Ah, that explains it. I had already marked all my changes for update,
that's what threw me off here. Thanks!
Linus Torvalds wrote:
>
> On Fri, 19 Aug 2005, Johnny Stenback wrote:
>> That made me assume that if I do:
>>
>> git-commit-script somedir
>>
>> it would *only* commit the changes I've made in "somedir", but it
>> appears to commit *all* files that have changed (and shows all files in
>> the list of changed files in the commit message it displays in the
>> editor), as if it's completely ignoring the <path> argument.
>>
>> Known problem? I got this using git that I pulled from kernel.org
>> earlier this morning.
>
> It works for me. You _should_ see something like
>
> #
> # Updated but not checked in:
> # (will commit)
> #
> # modified: somedir/somefile
> #
> #
> # Changed but not updated:
> # (use git-update-cache to mark for commit)
> #
> # modified: otherdir/anotherfile
> #
>
> which basically means that it will commit "somedir/somefile", but _not_
> commit "otherdir/anotherfile".
>
> However, one thing to look out for is that if you've marked any files for
> update (with git-update-cache) those will always be committed regardless
> of what arguments you give to "git commit". You can reset the index with
> "git reset" if you decided that you don't want to commit after all.
>
> (For example, if you do a "git commit --all", but decide not to commit
> after all by writing an empty commit message, that will already have
> marked all the files to be committed, so next time, even if you then use
> "git commit somedir", all the files in all the _other_ dirs have already
> been marked for update, so you'll see everything being committed).
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
jst
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Jan Veldeman @ 2005-08-19 18:27 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnx64u2p81k.fsf@arm.com>
Catalin Marinas wrote:
>
> The patch history feature was available in StGIT 0.1/0.2 releases
> where you should have run a 'stg commit' before 'stg refresh'. The
> commit was handling all the history changes, with separate commit
> messages and refresh was updating the main commit with 2 parents. I
> removed it in 0.3 after some people (I think it was Paul Jackson and
> Daniel Barkalow) convinced me that this would make it yet another SCM
> interface on top of GIT, which wasn't really my intention.
hmm, I must have misted those threads, I'll try to find and read them.
>
> The main problem with having multiple parents for a commit object
> corresponding to a patch is the upstream merging via 'git pull'. In
> general you don't want a gatekeeper to pull the history of your patch
> but the patch only.
I agree that such history should not be imported into the mainline, but such
history would still be very usefull when these patches won't be pushed to
mailine immediately. Also, when pushing to mainline, this history can easily
be removed by removing the branch/patch/parent files and refreshing (this
should off course be automated)
>
> > The patch below, together with the following script could be used to
> > make snapshots of the patch stack (I call it freeze, as I thought snapshot
> > was already going to be used for something else):
>
> 'snapshot' is not yet used for anything and I'm not sure how it is
> best to be implemented. I thought about simply saving the current HEAD
> into some .git/refs/heads/<file>, without preserving any history for
> the patch. A gitk on this file would show the patches as they were on
> the time of the snapshot creation. A new snapshot would remove this.
>
> It might be best for a per-patch history to have a separate file in
> <branch>/<patch>/, maybe called freeze, which keeps this history
> information. The top one should remain unchanged. Its hash could be
> accessed with the 'stg id /freeze' command (implemented
> yesterday). This file would only be updated via the 'freeze' command
> and its parent would be the previous freeze value.
>
> Would this be close to what you need?
>
hmm, not exactly, for example, when reordering the patches (including the
top one), I would like to see this in gitk.
Or when a patch has been dropped (amongst a lot of patches), it should be
easily spotted.
But even if the "stg-freeze" would not be incorporated into stgit, would it
still be possible to include some sort of extra parents directory. So that
the freeze can be implemented on top of stgit?
TIA
Best regards,
Jan
^ permalink raw reply
* [PATCH] git-rev-list: avoid crash on broken repository
From: Sergey Vlasov @ 2005-08-19 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
When following tags, check for parse_object() success and error out
properly instead of segfaulting.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
rev-list.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
f4ec41063d2f43b06b7c8e511108b4c9bf9e6ebe
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -418,6 +418,8 @@ static struct commit *get_commit_referen
if (tag_objects && !(object->flags & UNINTERESTING))
add_pending_object(object, tag->tag);
object = parse_object(tag->tagged->sha1);
+ if (!object)
+ die("bad object %s", sha1_to_hex(tag->tagged->sha1));
}
/*
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Jan Veldeman @ 2005-08-19 19:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnx64u2p81k.fsf@arm.com>
Catalin Marinas wrote:
>
> The patch history feature was available in StGIT 0.1/0.2 releases
> where you should have run a 'stg commit' before 'stg refresh'. The
> commit was handling all the history changes, with separate commit
> messages and refresh was updating the main commit with 2 parents. I
> removed it in 0.3 after some people (I think it was Paul Jackson and
> Daniel Barkalow) convinced me that this would make it yet another SCM
> interface on top of GIT, which wasn't really my intention.
I've quickly reread the threads about stg commit. Am I right to assume that
_all_ history was being recorded? Because this is not what I want. The
person controlling the archive should specify when to record the history.
So for example, you only tag (freeze) the history when exporting the
patches. When an error is being reported on that version, it's easy to view
it and also view the progress that was already been made on those patches.
Best regards,
Jan
^ 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