* Re: question about COMMIT_EDITMSG crlf
From: Juanma Barranquero @ 2009-01-14 9:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Frank Li, git
In-Reply-To: <496D91CE.1000504@viscovery.net>
On Wed, Jan 14, 2009 at 08:18, Johannes Sixt <j.sixt@viscovery.net> wrote:
> No, there isn't. But perhaps you can use WordPad instead of Notepad? There
> are reports that this worked.
Or Notepad2:
http://www.flos-freeware.ch/notepad2.html
Juanma
^ permalink raw reply
* Re: git-patches list?
From: Felipe Contreras @ 2009-01-14 8:44 UTC (permalink / raw)
To: Akira Kitada; +Cc: Junio C Hamano, git
In-Reply-To: <90bb445a0901130755t6ea98bcco6b6663d806dcc2e6@mail.gmail.com>
On Tue, Jan 13, 2009 at 5:55 PM, Akira Kitada <akitada@gmail.com> wrote:
> This list seems to be used as a bug tracker, discussing git development,
> user questions, announcement etc.
> I thought this is so unusual list that something should be wrong here,
> but it turned out that it looks working right in mysteryous way.
> I take that back now.
> Hmm, interesting...
Yes, it's definitely not the norm on other projects, but perhaps it should be.
That's how the linux kernel mailing list works. There are other
mailing lists for the different sub-systems, but there's no separation
between bugs, discussion and patches, which makes sense, because quite
often bugs and patches trigger discussions, and bug discussions
trigger patches.
Following this approach perhaps it would make sense to create a
separate mailing list for jgit and similar stuff.
--
Felipe Contreras
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Thomas Rast @ 2009-01-14 8:41 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]
skillzero@gmail.com wrote:
> I thought git would realize that master already had those 2 commits
> and not add them again when merging?
[later]
> That's what I was somewhat disappointed by. Even though the result of
> the commit had a different hash, I assumed git would keep some kind of
> internal per-commit hash so it could tell later that two commits were
> the same and not re-apply them.
I think there's an important misunderstanding here: merging A into B
does *not* have anything to do with commits, or history for that
matter, beyond the differences from $(git merge-base A B) to A and
B.[*]
Along the same lines, nothing is ever re-applied during merging.
git-merge just figures out that you made the same change on both
sides, so it must have been a good change, so it must go into the end
result. *How* you arrived at the same change---say, by
cherry-picking, or by getting the same result in that region from
otherwise different commits, or even from several commits---does *not*
matter in any way.
You can use 'git cherry', 'git log --left-right --cherry-pick', and
similar tools to find commits that are cherry-picked "duplicates", but
unless you rewrite history, they are there to stay.
[*] This is a simplification since as soon as the merge-base is not
unique, merge-recursive will actually start looking into history
further back.
--
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: git merge and cherry-pick and duplicated commits?
From: Boaz Harrosh @ 2009-01-14 8:38 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com>
skillzero@gmail.com wrote:
> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
>> Well, the way to do it is "careful planning".
>>
>> If you have a *slight* suspicion that some change *might* be needed on a
>> different branch, then:
>>
>> 1. you commit the change on a branch of its own that forks off of the
>> merge-base of *all* the branches that *might* need it;
>>
>> 2. next, you merge this fix-up branch into the branch where you need it
>> first, which is very likely your current topic-under-development.
>>
>> 3. Later you can merge the branch into the other branches if you find that
>> it is really needed.
>
> If I create a separate bug-fix-only branch X that forks from the
> latest common commit of all the branches that might need it and some
> of those branches already have commits after that merge base (e.g.
> branch Z is 5 commits after the common merge base by the time I fix
> the bug), will git be able to merge the new branch X into Z in a way
> that will allow me to also merge branch X into my original feature
> branch A and then later merge A into Z without duplicating the commit
> that is now in both branch X and Z?
>
> It seems like I'd run into my original duplicate commit problem
> because even though branch X was originally based off the same parent
> commit, it will have a different parent when it is merged into Z
> because Z is no longer at that common merge commit (it's 5 commits
> beyond it).
> --
No, if you use merges it will not duplicate. It will know exactly what
to do because it is the same commit in all branches.
Only git-cherry-pick will duplicate the same patch, but as a different
new commit. Then when merging the merge sees a merge conflict but since
it is exactly the same change it will accept it. The same happens if
two different patches have exact same hunk, the merge is smart to accept
the same change from two sources. What happen with cherry-pick is that all
the hunks match.
Boaz
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Johannes Sixt @ 2009-01-14 8:34 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901140008r59e429aeq3ce367e1bc7df71@mail.gmail.com>
[Please reply-to-all on this list, to keep Cc: list]
skillzero@gmail.com schrieb:
> On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>
>> Well, the way to do it is "careful planning".
>>
>> If you have a *slight* suspicion that some change *might* be needed on a
>> different branch, then:
>>
>> 1. you commit the change on a branch of its own that forks off of the
>> merge-base of *all* the branches that *might* need it;
>>
>> 2. next, you merge this fix-up branch into the branch where you need it
>> first, which is very likely your current topic-under-development.
>>
>> 3. Later you can merge the branch into the other branches if you find that
>> it is really needed.
>
> If I create a separate bug-fix-only branch X that forks from the
> latest common commit of all the branches that might need it and some
> of those branches already have commits after that merge base (e.g.
> branch Z is 5 commits after the common merge base by the time I fix
> the bug), will git be able to merge the new branch X into Z in a way
> that will allow me to also merge branch X into my original feature
> branch A and then later merge A into Z without duplicating the commit
> that is now in both branch X and Z?
>
> It seems like I'd run into my original duplicate commit problem
> because even though branch X was originally based off the same parent
> commit, it will have a different parent when it is merged into Z
> because Z is no longer at that common merge commit (it's 5 commits
> beyond it).
After you created the fixup, you have this situation:
o--o--o <- A (feature branch)
/
--o--x <- X (the fix-up branch)
\
o--o--o <- Z (probably your master)
You merge the fix-up into the feature branch and continue developing the
feature:
o--o--o--M--o--o <- A
/ /
--o--x-----' <- X
\
o--o--o <- Z
Other people need the fix in Z right now, so you merge it into Z as well:
o--o--o--M--o--o <- A
/ /
--o--x-----< <- X
\ \
o--o--o--N <- Z
You complete your feature and merge it into Z:
o--o--o--M--o--o <- A
/ / \
--o--x-----< \ <- X
\ \ \
o--o--o--N---------O <- Z
The fix-up commit is only once in your history.
-- Hannes
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Vladimir Pouzanov @ 2009-01-14 8:32 UTC (permalink / raw)
To: git
In-Reply-To: <76718490901131658l108852f2y9a25eb9133d6e96d@mail.gmail.com>
Jay Soffian <jaysoffian <at> gmail.com> writes:
> So you're adding the "use Carp..." and "warn..." lines.
>
> Then try the import again. That should at least show why the svn_delta
> temp file is being acquired twice.
Output is pretty long so I've put in on pastebin:
http://pastebin.com/m210be905
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Nanako Shiraishi @ 2009-01-14 8:31 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>
Quoting skillzero@gmail.com:
> The problem is, by the time I wanted to do the cherry-pick, I had
> already committed other stuff to the branch. I tried doing 'git rebase
> master branch' when on master and it just applied all the stuff from
> master to branch.
>
> Is there any way to apply a commit to 2 different branches (which have
> diverged) in a way that git will remember so that when the 2 branches
> merge later, it won't result in duplicate commits? I find that I often
> make changes that days or weeks later find out that some other branch
> needs that change and by then, there have been lots of commits to both
> branches after the commit I want.
Johennes Sixt gave a good answer. You need to think before making your commits while you are developing to separate what change belongs to common code base and what change belongs to a specific feature.
I was reading gitster's blog (he has several "git tutorial" articles recently) and he talks about how to commit a change to a branch different from what you originally developed it on in today's entry. You may find it instructive, but the procedure is after you think about it and decide what change goes where.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Kirill Smelkov @ 2009-01-14 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Potashev, git
In-Reply-To: <20090113093916.GA25471@landau.phys.spbu.ru>
On Tue, Jan 13, 2009 at 12:39:16PM +0300, Kirill Smelkov wrote:
> On Mon, Jan 12, 2009 at 03:27:44PM -0800, Junio C Hamano wrote:
> > Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
[...]
> > But doesn't this
> >
> > > From nobody Mon Sep 17 00:00:00 2001
> > > -From: A
> > > +From: A (zzz)
> > > U
> > > Thor
> > > - <a.u.thor@example.com>
> > > + <a.u.thor@example.com> (Comment)
> >
> > regress for people who spell their names like this?
> >
> > From: john.doe@email.xz (John Doe)
>
> I think everything is ok:
[...]
Just in case it got spam-detected again:
http://marc.info/?l=git&m=123183962105146&w=2
Thanks,
Kirill
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 8:08 UTC (permalink / raw)
To: git
In-Reply-To: <496D9572.2090303@viscovery.net>
On Tue, Jan 13, 2009 at 11:34 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Well, the way to do it is "careful planning".
>
> If you have a *slight* suspicion that some change *might* be needed on a
> different branch, then:
>
> 1. you commit the change on a branch of its own that forks off of the
> merge-base of *all* the branches that *might* need it;
>
> 2. next, you merge this fix-up branch into the branch where you need it
> first, which is very likely your current topic-under-development.
>
> 3. Later you can merge the branch into the other branches if you find that
> it is really needed.
If I create a separate bug-fix-only branch X that forks from the
latest common commit of all the branches that might need it and some
of those branches already have commits after that merge base (e.g.
branch Z is 5 commits after the common merge base by the time I fix
the bug), will git be able to merge the new branch X into Z in a way
that will allow me to also merge branch X into my original feature
branch A and then later merge A into Z without duplicating the commit
that is now in both branch X and Z?
It seems like I'd run into my original duplicate commit problem
because even though branch X was originally based off the same parent
commit, it will have a different parent when it is merged into Z
because Z is no longer at that common merge commit (it's 5 commits
beyond it).
^ permalink raw reply
* jgit merge question
From: David Birchfield @ 2009-01-14 7:55 UTC (permalink / raw)
To: git
In-Reply-To: <S1760244AbZANHqN/20090114074613Z+1959@vger.kernel.org>
Hi all,
My apologies in advance for the newbie question, and I hope this is
the correct forum - please let me know if there is a better place.
I have been working with the JGit library and with the pgm files and
other documentation I have been able to implement most of the basic
functions that I need for my testing application - including fetch.
This is great! However, I have not been able to successfully
implement the merge function with JGit. There is some reference to
this in the mail archive, but I cannot find any of the merge code that
is referenced in the distribution. I have tried to pull from
pgm.MergeBase.java, but that hasn't been successful.
My question:
Is there any sort of tutorial or reference code snippet that
implements merge? Or is there a trick to getting the MergeBase code
to achieve a basic merge?
Thanks in advance!
Best,
David
^ permalink raw reply
* git Thunderbird Synching
From: Nicholas LaRoche @ 2009-01-14 7:52 UTC (permalink / raw)
To: git
Has anyone tried to synch a Thunderbird profile between two computers
with git?
I want to do something like this with my main profile, but I'm concerned
that if I send/receive email on either machine independently that there
will be corruption in some of the files when I push back to my main box.
Regards,
Nick
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Johannes Sixt @ 2009-01-14 7:34 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>
skillzero@gmail.com schrieb:
> Is there any way to apply a commit to 2 different branches (which have
> diverged) in a way that git will remember so that when the 2 branches
> merge later, it won't result in duplicate commits? I find that I often
> make changes that days or weeks later find out that some other branch
> needs that change and by then, there have been lots of commits to both
> branches after the commit I want.
Well, the way to do it is "careful planning".
If you have a *slight* suspicion that some change *might* be needed on a
different branch, then:
1. you commit the change on a branch of its own that forks off of the
merge-base of *all* the branches that *might* need it;
2. next, you merge this fix-up branch into the branch where you need it
first, which is very likely your current topic-under-development.
3. Later you can merge the branch into the other branches if you find that
it is really needed.
If you don't have the slight suspicion, then you have to take the
second-best route, namely to cherry-pick the commit onto a branch just
like in 1. above, and continue with 2. and 3. In this case you have the
commit twice, but not more than that.
-- Hannes
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 7:33 UTC (permalink / raw)
To: git
In-Reply-To: <5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com>
I guess maybe a better question is how do people normally handle
situations like mine where I did some work on branch X and I later
realize I need only a portion of that work on branch Y? I'm not sure
how I can change my workflow to completely eliminate these situations.
For example, I often start a branch to add a new feature and I end up
fixing bug A on that branch. Then other people on my team decide they
need the fix for bug A immediately and can't wait for me to finish my
feature branch and do a full merge.
Is there some way I can change my workflow such that I can fix bug A
(maybe on a separate branch?) and somehow apply it to both both
branches in a way that won't result in duplicate commits?
Does this kind of thing ever happen with the Linux kernel or git
itself: somebody does a fix as part of their topic branch and the
Linux kernel or git master wants that particular fix now, but is not
ready for the full topic branch? Would they just suggest the fix be
separated into its own topic branch and that merged? If so, how would
that new topic branch merge into the original topic branch without
resulting in a duplicate commit when it's later merged into master?
^ permalink raw reply
* Re: question about COMMIT_EDITMSG crlf
From: Johannes Sixt @ 2009-01-14 7:18 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901132117l7947157fw2922465a9b3945dc@mail.gmail.com>
Frank Li schrieb:
> I want to use notepad replace default vim at commit message editor.
> git commit will create COMMIT_EDITMSG at .git directory. This file is
> unix text mode.
> Is there any config change it to windows text mode?
No, there isn't. But perhaps you can use WordPad instead of Notepad? There
are reports that this worked.
You could also write a wrapper script that transforms the file before it
calls Notepad on it (untested):
#!/bin/bash
sed -e $'s/\r?$/\r/' < "$1" > .git/tmp$$ &&
mv .git/tmp$$ "$1" &&
notepad "$1"
I think git commit removes the trailing CRs automatically, so they don't
end up in the commit message.
-- Hannes
^ permalink raw reply
* Re: question about COMMIT_EDITMSG crlf
From: Junio C Hamano @ 2009-01-14 7:04 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660901132117l7947157fw2922465a9b3945dc@mail.gmail.com>
"Frank Li" <lznuaa@gmail.com> writes:
> I want to use notepad replace default vim at commit message editor.
> git commit will create COMMIT_EDITMSG at .git directory. This file is
> unix text mode.
> Is there any config change it to windows text mode?
Nothing I can think of, other than using customized commit templates,
which I suspect is a bit overkill and at the same time misses the point
for this use case.
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Johannes Sixt @ 2009-01-14 7:02 UTC (permalink / raw)
To: thestar; +Cc: Brad King, Git Mailinglist
In-Reply-To: <20090114165447.qdlwqqfnk4goccgg@webmail.fussycoder.id.au>
thestar@fussycoder.id.au schrieb:
>> Johannes Sixt wrote:
>>> Consider this: You accidentally push a branch with confidential data
>>> to a
>>> public repository. You notice it early, and quickly delete the branch
>>> using 'git push the-repo :refs/heads/that-branch'. At this time the
>>> objects with the confidential data are still lingering in the public
>>> repository. But with the current behavior noone can access them even if
>>> the SHA1 happens to be known.
>
> Doesn't this line of reasoning only apply to the ssh and git transports?
> (ie, the file and rsync transport would retrieve it regardless)
You are right. Http and rsync would happily ship the object.
-- Hannes
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: Johannes Sixt @ 2009-01-14 7:01 UTC (permalink / raw)
To: Brad King; +Cc: Git Mailinglist
In-Reply-To: <496D0E65.3000200@kitware.com>
Brad King schrieb:
> Johannes Sixt wrote:
>> Consider this: You accidentally push a branch with confidential data to a
>> public repository. You notice it early, and quickly delete the branch
>> using 'git push the-repo :refs/heads/that-branch'. At this time the
>> objects with the confidential data are still lingering in the public
>> repository. But with the current behavior noone can access them even if
>> the SHA1 happens to be known.
>
> Might a repack (perhaps an automatic one) put the object in a pack
> (perhaps in a delta chain) that can be fetched through another ref?
No, assuming that-branch was the only ref that contained the objects.
Even if the repack happens before the branch is deleted, the objects that
were *only* in that-branch will not be sent out.
-- Hannes
^ permalink raw reply
* Re: [PATCH next] git-notes: fix printing of multi-line notes
From: Junio C Hamano @ 2009-01-14 6:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tor Arne Vestbø, git
In-Reply-To: <alpine.DEB.1.00.0901132339270.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 13 Jan 2009, Tor Arne Vestbø wrote:
>
>> The line length was read from the same position every time,
>> causing mangled output when printing notes with multiple lines.
>>
>> Also, adding new-line manually for each line ensures that we
>> get a new-line between commits, matching git-log for commits
>> without notes.
>>
>> Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
>> ---
>
> Patch looks good, so
>
> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> For extra browny points, you could add a test with multi-line notes.
Yeah, not just "extra", having tests is a good way to make sure a new
feature like this evolves healthily.
Tor?
^ permalink raw reply
* Re: .ft tag in man
From: Todd Zullinger @ 2009-01-14 6:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bill lam, git
In-Reply-To: <7veiz678m2.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2258 bytes --]
Junio C Hamano wrote:
> bill lam <cbill.lam@gmail.com> writes:
>
>> The diagram in man contain some .ft tag, eg inside
>> PAGE=less git help rebase
>> it contains
>>
>> .ft C
>> A---B---C topic
>> /
>> D---E---F---G master
>> .ft
>
> No, I do not see that neither on my Debian nor on k.org's FC 9.
I began seeing this on Fedora 10. Defining DOCBOOK_XSL_172 fixed
that issue, but seems to have caused another. :/
For example, in git-diff.1, without DOCBOOK_XSL_172, I see:
.ft C
$ git diff (1)
$ git diff --cached (2)
$ git diff HEAD (3)
.ft
With DOCBOOK_XSL_172, I get this:
$ git diff ▓fB(3)▓fR
$ git diff --cached ▓fB(2)▓fR
$ git diff HEAD ▓fB(3)▓fR
The '.ft' problem is gone, but '\fB' and '\fR' are replaced by '▓fB'
and '▓fR', respectively. The paragraphs that follow such a list of
commands show more ugliness:
⌂sp ▓fB1. ▓fRChanges in the working tree not yet staged for the
next commit. ⌂br ▓fB2. ▓fRChanges between the index and your
last commit; what you would be committing if you run "git commit"
without "-a" option. ⌂br ▓fB3. ▓fRChanges in the working tree
since your last commit; what you would be committing if you run
"git commit -a" ⌂br
Defining ASCIIDOC8 seems to have no effect on this problem.
> Perhaps you are using different version of asciidoc/docbook/xmlto
> toolchain?
On Fedora 10, these are the versions:
asciidoc-8.2.5-2.fc9
docbook-dtds-1.0-41.fc10
docbook-style-xsl-1.74.0-4.fc10
xmlto-0.0.21-2.fc10
Fedora 9 has:
asciidoc-8.2.5-2.fc9
docbook-dtds-1.0-38.fc9
docbook-style-xsl-1.73.2-10.fc9
xmlto-0.0.20-3.fc9
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once ... in the wilds of Afghanistan, I lost my corkscrew, and we were
forced to live on nothing but food and water for days.
-- W.C. Fields
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: skillzero @ 2009-01-14 6:21 UTC (permalink / raw)
To: git
In-Reply-To: <5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com>
On Tue, Jan 13, 2009 at 9:31 PM, Brian Gernhardt
<benji@silverinsanity.com> wrote:
> After the cherry-picks, the repo looks like this:
>
> o-o-A'-B' (master)
> \
> o-A-B-o (branch:2daf23)
>
> A and A' are different commits. Same with B and B'. If you check the SHA1
> of master at this point, it will NOT be 702fd... (B). Cherry pick creates a
> new commit that (as far as git is concerned) is totally unrelated.
That's what I was somewhat disappointed by. Even though the result of
the commit had a different hash, I assumed git would keep some kind of
internal per-commit hash so it could tell later that two commits were
the same and not re-apply them.
> The simplest method is to rebase branch after doing the cherry-picks. This
> should only be done if your branch has not been published.
The problem is, by the time I wanted to do the cherry-pick, I had
already committed other stuff to the branch. I tried doing 'git rebase
master branch' when on master and it just applied all the stuff from
master to branch.
Is there any way to apply a commit to 2 different branches (which have
diverged) in a way that git will remember so that when the 2 branches
merge later, it won't result in duplicate commits? I find that I often
make changes that days or weeks later find out that some other branch
needs that change and by then, there have been lots of commits to both
branches after the commit I want.
^ permalink raw reply
* Re: How to pull remote branch with specified commit id?
From: thestar @ 2009-01-14 5:54 UTC (permalink / raw)
To: Brad King; +Cc: Johannes Sixt, Git Mailinglist
In-Reply-To: <496D0E65.3000200@kitware.com>
> Johannes Sixt wrote:
>> Consider this: You accidentally push a branch with confidential data to a
>> public repository. You notice it early, and quickly delete the branch
>> using 'git push the-repo :refs/heads/that-branch'. At this time the
>> objects with the confidential data are still lingering in the public
>> repository. But with the current behavior noone can access them even if
>> the SHA1 happens to be known.
Doesn't this line of reasoning only apply to the ssh and git transports?
(ie, the file and rsync transport would retrieve it regardless)
^ permalink raw reply
* Re: .ft tag in man
From: Junio C Hamano @ 2009-01-14 5:35 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090114052126.GA6849@b2j>
bill lam <cbill.lam@gmail.com> writes:
> The diagram in man contain some .ft tag, eg inside
> PAGE=less git help rebase
> it contains
>
> .ft C
> A---B---C topic
> /
> D---E---F---G master
> .ft
No, I do not see that neither on my Debian nor on k.org's FC 9.
Perhaps you are using different version of asciidoc/docbook/xmlto
toolchain?
I think we added compatibility definitions in our Makefile to deal with
differences between AsciiDoc 7 vs 8, but I do not recall offhand what
misformatting one would get if it is set incorrectly..
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Brian Gernhardt @ 2009-01-14 5:31 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0901131840v5c7ce0c7l3f87c03caabf68de@mail.gmail.com>
On Jan 13, 2009, at 9:40 PM, skillzero@gmail.com wrote:
> I created a branch from master, did a commit (8e9fdd), then did 2 more
> commits (11c59c and 7024d), then did another commit (2daf23). From
> master, I did a commit (47bd1b) then cherry-pick'd 2 commits from the
> branch (11c59c and 7024d). When merged the branch into master, I see
> the 2 cherry-picked commits twice in the log (once from the original
> cherry-pick's and again from the merge).
Before the cherry-picks, your repository looks like this
o-o (master: 47bd1b)
\
o-A-B-o (branch:2daf23)
A and B are the two commits you cherry-picked (11c59c and 7024d)
After the cherry-picks, the repo looks like this:
o-o-A'-B' (master)
\
o-A-B-o (branch:2daf23)
A and A' are different commits. Same with B and B'. If you check the
SHA1 of master at this point, it will NOT be 702fd... (B). Cherry
pick creates a new commit that (as far as git is concerned) is totally
unrelated.
After the merge, you get:
o-o-A'-B'-o (master)
\ /
o-A-B-o
Since git has no knowledge that the cherry-picked (A' B') commits are
related to their originals (A B), it displays both to you. If you
want, you can use the -x flag when you use "git cherry-pick" to add a
line that describes the original source of the patch in the new commit
which eases confusion when you look at the history, but will not stop
them from being displayed.
(The reason git will still display them is that the cherry-picked
commits may be different if there were conflicting changes on the
branches. Also, hiding those commits would give a false view of
history since the changes were actually added to the repository
twice. Using gitk or "git log --graph" will show the commits on two
different lines of development.)
> I thought git would realize that master already had those 2 commits
> and not add them again when merging?
The simplest method is to rebase branch after doing the cherry-picks.
This should only be done if your branch has not been published. From
after the cherry-picks:
o-o-A'-B' (master)
\
o-A-B-o (branch:2daf23)
"git rebase master branch" would give you
o-o-A'-B' (master)
\
o'-o' (branch)
Git should detect that the changes from A and B were already present
in master during the rebase and skip the commits.
~~ Brian Gernhardt
^ permalink raw reply
* question about COMMIT_EDITMSG crlf
From: Frank Li @ 2009-01-14 5:17 UTC (permalink / raw)
To: git
I want to use notepad replace default vim at commit message editor.
git commit will create COMMIT_EDITMSG at .git directory. This file is
unix text mode.
Is there any config change it to windows text mode?
^ permalink raw reply
* .ft tag in man
From: bill lam @ 2009-01-14 5:21 UTC (permalink / raw)
To: git
The diagram in man contain some .ft tag, eg inside
PAGE=less git help rebase
it contains
.ft C
A---B---C topic
/
D---E---F---G master
.ft
Is that intended or just an artefact?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩244 柳宗元 江雪
千山鳥飛絕 萬徑人蹤滅 孤舟簑笠翁 獨釣寒江雪
^ 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