* Re: [bug?] checkout -m doesn't work without a base version
From: Pete Harlan @ 2011-12-12 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcpqj4vr.fsf@alter.siamese.dyndns.org>
On 12/08/2011 10:27 AM, Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
>
>> to "ours" and "theirs". (The same thing happens in the 3-way merge
>> case.)
>
> That is entirely expected. "checkout -m" does not know or care _how_ the
> index came to the conflicted state and reproduces the three-way conflicted
> state in the file in the working tree solely from the contents of the
> index which records only what the common thing looked like (stage #1),
> what one side looked like (stage #2) and what the other side looked like
> (stage #3) before the mergy operation began, so there is no way for it to
> say "the other side came from foo/blah branch". There are even cases where
> the conflict originally came not from any branch (think "am -3").
Thanks for taking the time to explain this.
Here's a test that strips branch info off the conflict lines before
verifying checkout -m, and it tests both the 2-way and 3-way cases.
The 3-way works before and after your patch; the 2-way fails before
your patch but passes after. If the you think the test is worth
including feel free to fold it in to your patch.
--Pete
-------------------
>From a4522e06515231034c1ada65e1e91614a6c4809e Mon Sep 17 00:00:00 2001
From: Pete Harlan <pgit@pcharlan.com>
Date: Tue, 6 Dec 2011 23:01:28 -0800
Subject: [PATCH] Test 'checkout -m -- path'
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
t/t2023-checkout-m.sh | 47
+++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100755 t/t2023-checkout-m.sh
diff --git a/t/t2023-checkout-m.sh b/t/t2023-checkout-m.sh
new file mode 100755
index 0000000..1a40ce0
--- /dev/null
+++ b/t/t2023-checkout-m.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+
+test_description='checkout -m -- <conflicted path>
+
+Ensures that checkout -m on a resolved file restores the conflicted file'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ test_tick &&
+ test_commit both.txt both.txt initial &&
+ git branch topic &&
+ test_commit modified_in_master both.txt in_master &&
+ test_commit added_in_master each.txt in_master &&
+ git checkout topic &&
+ test_commit modified_in_topic both.txt in_topic &&
+ test_commit added_in_topic each.txt in_topic
+'
+
+test_must_fail git merge master
+
+clean_branchnames () {
+ # Remove branch names after conflict lines
+ sed 's/^\([<>]\{5,\}\) .*$/\1/'
+}
+
+test_expect_success '-m restores 2-way conflicted+resolved file' '
+ cp each.txt each.txt.conflicted &&
+ echo resolved >each.txt &&
+ git add each.txt &&
+ git checkout -m -- each.txt &&
+ clean_branchnames <each.txt >each.txt.cleaned &&
+ clean_branchnames <each.txt.conflicted >each.txt.conflicted.cleaned &&
+ test_cmp each.txt.conflicted.cleaned each.txt.cleaned
+'
+
+test_expect_success '-m restores 3-way conflicted+resolved file' '
+ cp both.txt both.txt.conflicted &&
+ echo resolved >both.txt &&
+ git add both.txt &&
+ git checkout -m -- both.txt &&
+ clean_branchnames <both.txt >both.txt.cleaned &&
+ clean_branchnames <both.txt.conflicted >both.txt.conflicted.cleaned &&
+ test_cmp both.txt.conflicted.cleaned both.txt.cleaned
+'
+
+test_done
--
1.7.8
^ permalink raw reply related
* Re: best way to fastforward all tracking branches after a fetch
From: Hallvard B Furuseth @ 2011-12-11 22:22 UTC (permalink / raw)
To: Stefan Haller; +Cc: Gelonida N, git
In-Reply-To: <1kc4qnw.1xgi3yf14oaw7gM%lists@haller-berlin.de>
Stefan Haller writes:
>Gelonida N <gelonida@gmail.com> wrote:
>
>> What is the best way to fastforward all fastforwardable tracking
>> branches after a git fetch?
>
> Here's a script that does this. It isn't very well tested, I hope I
> didn't miss any edge cases. Use at your own risk.
Local branches can track each other. So the script needs to toposort
the branches, or to loop until either nothing was done or an error
happened. (The latter to prevent an eternal loop on error.)
I've wished for a more limited 'git ff' command than this:
- git update-ref --ff-only, and branch/fetch options based on this.
- Fast-forward only the branches tracking one particular remote/branch,
and maybe branches tracking the fast-forwarded branches.
- Fast-forward to another remote or branch than the tracked one.
I have a few aliases for it, but never thought much of a good common
design.
--
Hallvard
^ permalink raw reply
* Re: Question about commit message wrapping
From: Andrew Ardill @ 2011-12-11 22:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Sidney San Martín, git
In-Reply-To: <201112102030.15504.jnareb@gmail.com>
Hi,
On Sunday, December 11, 2011, Jakub Narebski <jnareb@gmail.com> wrote:
...
> Additional and the more serious problem with wrapping on output is
> related to backward compatibility. If you have commit message that is
> wrapped e.g. to 80 characters, and you wrap on output to 72 characters,
> you would get ugly and nigh unreadable ragged output
For what it's worth, I do a lot of reading emails on my phone, which
force wraps line-length to the width of the display (not a set number
of characters).
This is always less than 80.
Emails on this list are almost exclusively sent pre-wrapped to 80
character line lengths.
The result is exactly the kind of ragged output you used in your
example. Changing this behaviour may break backwards compatibility,
but it is already broken for 'future' compatibility.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Auto update submodules after merge and reset
From: Andreas T.Auer @ 2011-12-11 21:15 UTC (permalink / raw)
To: Phil Hord; +Cc: Jens Lehmann, git
In-Reply-To: <CABURp0rcT2FR3uOmhyPUV5W3pu7WuJzjXktmUq0eb4nOiUwDKA@mail.gmail.com>
On 10.12.2011 00:57 Phil Hord wrote:
> On Thu, Dec 8, 2011 at 4:13 AM,
> <andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:
>
> Yes, but maybe you can update this information in the .gitmodules
> file easily with a command. Maybe it could be something simpler
> than "git sync-gitmodules-branches", but that is essentially what it
> would do: it would save the current branch in each submodule as the
> "tracked" branch in the .gitmodules file.
Ok, I have read a better description of the "floating submodule" model
now, so it is a different use case and somehow it makes sense. In that
case there are probably just a few branches that you would like to
follow, maybe an "unstable" for the newest development or "stable" for
the current release or some maintenance branches.
> Now this makes sense. I want the same thing. I want to preserve
> history on "old" commits, but I want to "advance to tip" on "new"
> commits.
>
> The trouble, I think, is in telling the difference between "old" and
> "new". I think it means there is a switch, like --auto-follow (or
> --no-auto-follow for the alternate if core.auto_follow is set). But
> having a config option as the default is likely to break lots of
> scripts.
In my use case the branches on the submodules follow the superproject
and (mostly) versions that are committed there, it just adds the
possibility to keep on working without checking out a branch after an
update and without colliding with existing branchnames in the submodule.
The other use case wants to follow the commits of that other submodule
without checking the corresponding gitlinks into the superproject. But
wouldn't it also make sense here to define actually a mapping in the
.gitmodule that says "if the branch 'develop' is checkedout in the
supermodule then with every submodule update automatically pull the
newest 'unstable' commit from the submodule"? Or for "master" follow
"stable" or for the "maint" branch follow updates in the "bugfixes" branch.
For example
[submodule "commonlib"]
update = heads develop:unstable master:stable maint:bugfixes
So whenever a defined branch is checked out in the superproject the
mapped branch will be checked out in the submodule ("new" commit), but
if a (e.g. tagged) commit is checked out ("old" commit) then the gitlink
in the superproject is used to check out the referenced commit in the
submodule.
In http://thread.gmane.org/gmane.comp.version-control.git/183837 was
discussed whether the gitlink in the superproject should be set to
all-zero if updates follow the tip or maybe use the SHA1 of the commit
when the submodule was added. I think the gitlink should be updated
everytime when a new commit in the superproject is created.
^ permalink raw reply
* git 1.7.7.3: BUG - please make git mv -f quiet
From: Jari Aalto @ 2011-12-11 21:22 UTC (permalink / raw)
To: git
Every time I do:
git mv -f FROM TO
Git displays:
warning: destination exists; will overwrite!
Please don't display anything other than errors (no write permission....).
The "-f" is like with mv(1), cp(1); there is nothing than can be done
afterwards, so the message is redundant and obstructing.
If messages are needed, please add option:
-v, --verbose
Jari
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Martin Langhoff @ 2011-12-11 20:43 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <4EE5121D.2050002@gmail.com>
On Sun, Dec 11, 2011 at 3:27 PM, Gelonida N <gelonida@gmail.com> wrote:
> Agreed. it might be reasonable to ignore the current branch if it wasn't
> pulled.
Actually, what this means is that this should be an enhancement to git
pull ("git pull --all") because pull means fetch + merge.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Andreas Schwab @ 2011-12-11 20:30 UTC (permalink / raw)
To: Gelonida N; +Cc: git, Sitaram Chamarty
In-Reply-To: <4EE50B5A.3000706@gmail.com>
Gelonida N <gelonida@gmail.com> writes:
> On 12/11/2011 07:22 PM, Jakub Narebski wrote:
>> You can use 'upstream' field name in git-for-each-ref invocation,
>> for example
>>
>> git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
>> grep -e ' [^ ]' |
>> sed -e 's/ .*$//
>>
> Thanks
>
>
>
>> This could probably be done using only sed -- grep is not necessary.
> I think the equivalent would be:
> sed '/ [^ ]/ s/ .*$//'
You need to suppress printing the non-matching lines.
sed -n '/ [^ ]/ s/ .*$//p'
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Gelonida N @ 2011-12-11 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <1kc4qnw.1xgi3yf14oaw7gM%lists@haller-berlin.de>
On 12/11/2011 09:14 PM, Stefan Haller wrote:
> Gelonida N <gelonida@gmail.com> wrote:
>
>> What is the best way to fastforward all fastforwardable tracking
>> branches after a git fetch?
>
> Here's a script that does this. It isn't very well tested, I hope I
> didn't miss any edge cases. Use at your own risk.
>
> (It doesn't fastforward the branch you're on, on the assumtion that if
> you said git fetch instead of git pull, you probably had a reason.)
Agreed. it might be reasonable to ignore the current branch if it wasn't
pulled.
Thanks a lot for the script. I will play with it.
>
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Stefan Haller @ 2011-12-11 20:14 UTC (permalink / raw)
To: Gelonida N, git
In-Reply-To: <jbvj5o$skt$1@dough.gmane.org>
Gelonida N <gelonida@gmail.com> wrote:
> What is the best way to fastforward all fastforwardable tracking
> branches after a git fetch?
Here's a script that does this. It isn't very well tested, I hope I
didn't miss any edge cases. Use at your own risk.
(It doesn't fastforward the branch you're on, on the assumtion that if
you said git fetch instead of git pull, you probably had a reason.)
========= 8< =========
#!/bin/sh
currentbranch="`git symbolic-ref HEAD 2>/dev/null`"
git for-each-ref --shell --format='ref=%(refname);upstream=%(upstream)' \
refs/heads | \
while read entry
do
eval "$entry"
# skip the current branch
test "$ref" = "$currentbranch" && continue
# skip branches that have no upstream
test -z "$upstream" && continue
# skip if upstream doesn't have any new commits
if [ -z "`git rev-list "$ref..$upstream"`" ]; then
echo "${ref#refs/heads/} is up to date"
continue
fi
# error if there are local commits
if [ -n "`git rev-list "$upstream..$ref"`" ]; then
echo "${ref#refs/heads/} has local commits; can't fast-forward"
continue
fi
echo "${ref#refs/heads/} -> ${upstream#refs/remotes/}"
git update-ref -m ff-all-branches "$ref" "$upstream"
done
========= >8 =========
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: [RFC/PATCH 0/7] some sequencer loose ends (Re: Fix revert --abort on Windows)
From: Jonathan Nieder @ 2011-12-11 19:58 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Jay Soffian
In-Reply-To: <20111210124644.GA22035@elie.hsd1.il.comcast.net>
Jonathan Nieder wrote:
> Here are patches to address some UI warts
[... rambling cover letter snipped ...]
Let's try that again. :)
Current git has a somewhat odd behavior when cherry-picking multiple
commits and running into a conflict in the _last_ commit of the
series. Imagine the following sequence of operations:
1. git cherry-pick simplething simplethingtwo complexthing
2. CONFLICT.
3. git cherry-pick --abort
It would be most consistent for the entire cherry-pick sequence to be
rolled back, so the user can come up with some other sequence of
commits to try. After all, that's what happens if a conflict is
encountered applying simplethingtwo and the user asks to abort.
Instead, by the time complexthing is being applied, git has forgotten
about the multi-pick sequence entirely. And the --abort does not even
warn about this weird state --- it just cancels complexthing and
leaves the earlier commits applied.
This is an edge case, but I think it's worth fixing. Patch 5/7 does
so.
In the same vein, now imagine a different sequence of operations:
1. git cherry-pick simplething complexthing morecommits...
2. CONFLICT.
3. git reset --merge
4. git cherry-pick --continue
It would be sensible for this to remove the conflicted patch and go
on with the remaining ones, right? But instead, "git reset"
automagically removes the sequencer state, so you can't even use
git cherry-pick --abort any more. Well, you can, if you say the
magic words "mv .git/sequencer-old .git/sequencer", but nobody
actually tells you that.
How did we ever let this in? "git reset" already has well defined
semantics that have nothing to do with this. Patches 6/7 and 7/7
would help us forget this UI mistake (and I believe it was a mistake)
ever happened.
Patch 2 makes cherry-pick --continue behave a little more like
rebase --continue, for people who like to learn by analogy.
Patches 1 and 3 are just code style things.
Patch 4 is the basic building block that makes patch 5 possible: it
teaches "git cherry-pick" to treat picks of a single commit named on
the command line differently from the more complex multi-picks
requested with general rev-list arguments. Single-pick is all that
git cherry-pick originally supported, and in some details it has to
differ from multi-pick (for example, "git commit" after resolving
conflicts after a conflicted single-pick needs to be enough to clear
the state). As a side-benefit, we get the ability to do a single-pick
in the middle of a multi-pick, which is kind of cool and handy from
time to time.
I am interested in sanity checking of the patches and testing. It
would be pleasant to find comments like "yeah, that looks good" or
"what are you thinking?! I ran into the following bug" arriving in my
inbox.
Incidentally, I'd like to apologize about not protesting more about
these things (and even having suggested some of them) as they
happened. Instead of exercising careful oversight over the sanity of
patches that passed through my mailbox, I had some strange idea of
using the Socratic method to help others learn to explore the design
space and sanity-check findings themselves...
Thanks for reading.
Ciao,
Jonathan
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Gelonida N @ 2011-12-11 19:58 UTC (permalink / raw)
To: git; +Cc: Sitaram Chamarty
In-Reply-To: <m3ehwbge8f.fsf@localhost.localdomain>
On 12/11/2011 07:22 PM, Jakub Narebski wrote:
> Don't remove people from Cc, please.
OK,
>
> Gelonida N <gelonida@gmail.com> writes:
>> On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
>>
>> In order to save time I'd like to avoid checking out local branches.
>
> You can use 'upstream' field name in git-for-each-ref invocation,
> for example
>
> git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
> grep -e ' [^ ]' |
> sed -e 's/ .*$//
>
Thanks
> This could probably be done using only sed -- grep is not necessary.
I think the equivalent would be:
sed '/ [^ ]/ s/ .*$//'
>
>> Ideally I would even like to avoid checking out branches, which don't
>> need to be forwarded.
>
> You can use git-update-ref plumbing, but you would have to do the
> check if it does fast-forward yourself, and provide reflog message
> yourself too.
>
True this would probably be fastest. Will read the docs a little to
understand exactly what you're doing. I'm not that much used to all the
commands used in the script.
> Something like
>
> git for-each-ref '--format=%(refname) %(upstream)' |
> while read refname upstream
> do
> # there is upstream
> test -n "$upstream" || break
> # and if fast-forwards
> test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> git update-ref -m "$message" $refname $upstream
> done
>
>> I also had to remember on which branch I was in order to avoid, that I
>> am at a random branch after running the script.
>>
>
> Don't use git-branch in scripting. See __git_ps1 function in
> contrib/completion/git-completion.bash how it can be done:
>
> b="$(git symbolic-ref HEAD 2>/dev/null)" ||
> b="$(git rev-parse --verify HEAD)"
>
> Nb. the second part is here only if there is possibility that you are
> on detached HEAD (unnamed branch).
>
> HTH (hope that helps)
It definitely helps. Thanks a lot.
It's always good to see how one can do better after some attempts o some
self made clumsy scripts not suing all the features of git.
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Jakub Narebski @ 2011-12-11 19:53 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Gelonida N, git, Sitaram Chamarty
In-Reply-To: <m2hb176iiy.fsf@igel.home>
Andreas Schwab wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Something like
> >
> > git for-each-ref '--format=%(refname) %(upstream)' |
> > while read refname upstream
> > do
> > # there is upstream
> > test -n "$upstream" || break
Here you should probably also check if we are already up-to-date:
test $(git rev-parse $upstream) = $(git rev-parse $refname) || continue
> > # and if fast-forwards
> > test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> > git update-ref -m "$message" $refname $upstream
> > done
>
> You probably meant s/break/continue/.
Yes, sorry about that.
BTW. git-update-ref invocation can be replaced by Sitaram's suggestion:
git branch -f $refname $upstream
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Andreas Schwab @ 2011-12-11 19:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Gelonida N, git, Sitaram Chamarty
In-Reply-To: <m3ehwbge8f.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Something like
>
> git for-each-ref '--format=%(refname) %(upstream)' |
> while read refname upstream
> do
> # there is upstream
> test -n "$upstream" || break
> # and if fast-forwards
> test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> git update-ref -m "$message" $refname $upstream
> done
You probably meant s/break/continue/.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Sitaram Chamarty @ 2011-12-11 18:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Gelonida N, git
In-Reply-To: <m3ehwbge8f.fsf@localhost.localdomain>
2011/12/11 Jakub Narebski <jnareb@gmail.com>:
> Don't remove people from Cc, please.
>
> Gelonida N <gelonida@gmail.com> writes:
>> On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
>> > On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
>
>> > So what you want would boil down to this script (untested):
>> >
>> > #!/bin/bash
>> > git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
>> >
>> > for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
>> > do
>> > git checkout $b
>> > git merge --ff-only @{u}
>> > done
>>
>> Is there no way to distinguish tracking branches from other branches?
>> without checking them out?
>>
>> In order to save time I'd like to avoid checking out local branches.
>
> You can use 'upstream' field name in git-for-each-ref invocation,
> for example
>
> git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
> grep -e ' [^ ]' |
> sed -e 's/ .*$//
>
> This could probably be done using only sed -- grep is not necessary.
>
>> Ideally I would even like to avoid checking out branches, which don't
>> need to be forwarded.
>
> You can use git-update-ref plumbing, but you would have to do the
> check if it does fast-forward yourself, and provide reflog message
> yourself too.
if it's not the currently checked-out branch, 'git branch -f foo
origin/foo' seems to work fine. However, it only updates the branch
reflog, not the HEAD reflog also, naturally.
FWIW...
> Something like
>
> git for-each-ref '--format=%(refname) %(upstream)' |
> while read refname upstream
> do
> # there is upstream
> test -n "$upstream" || break
> # and if fast-forwards
> test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
> git update-ref -m "$message" $refname $upstream
> done
>
>> I also had to remember on which branch I was in order to avoid, that I
>> am at a random branch after running the script.
>>
>> I could imagine something like my snippet below , though I guess,
>> there's something more elegant.
>>
>> git stash
>> mybranch=`git branch | sed -n 's/\* *//p'`
>> # do_script . . .
>> git checkout $mybranch
>> git stash apply
>
> Don't use git-branch in scripting. See __git_ps1 function in
> contrib/completion/git-completion.bash how it can be done:
>
> b="$(git symbolic-ref HEAD 2>/dev/null)" ||
> b="$(git rev-parse --verify HEAD)"
>
> Nb. the second part is here only if there is possibility that you are
> on detached HEAD (unnamed branch).
>
> HTH (hope that helps)
> --
> Jakub Narębski
--
Sitaram
^ permalink raw reply
* Breakage (?) in configure and git_vsnprintf()
From: Michael Haggerty @ 2011-12-11 18:42 UTC (permalink / raw)
To: git discussion list; +Cc: Michal Rokos, Brandon Casey
I found a mysterious bunch of test suite failures when I compiled git on
a 64-bit Linux 3.0.0 using gcc 4.6.1:
git clean -f -x -d
make clean
make configure
./configure --prefix=$HOME CFLAGS='-g -O0 -std=c89 -Wall -Werror'
make test
The failure unexpectedly depended on the presence of all three compiler
options "-std=c89 -Wall -Werror". There is no difference between -O0
and -O2. The breakage is in v1.7.7, v1.7.8, and master (I didn't try
older versions).
I have been using "-std=c89" when compiling to avoid accidentally using
newer C features. Perhaps that is unwise :-)
The same test succeeds on 32-bit Linux 2.6.32 using gcc 4.4.3.
There seem to be two levels to the problem:
1. With this choice of compiler options, configure incorrectly convinces
itself that the system's snprintf() is broken and sets
SNPRINTF_RETURNS_BOGUS. From config.log:
configure:5368: checking whether snprintf() and/or vsnprintf() return
bogus value
configure:5406: cc -o conftest -g -O0 --std=c89 -Wall -Werror
conftest.c >&5
conftest.c: In function 'test_vsnprintf':
conftest.c:62:5: error: implicit declaration of function 'vsnprintf'
[-Werror=implicit-function-declaration]
conftest.c: In function 'main':
conftest.c:72:5: error: implicit declaration of function 'snprintf'
[-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
configure:5406: $? = 1
configure: program exited with status 1
According to the manpage, snprintf() and vsnprintf() are truly not
supported for "-std=c89" and indeed they are not declared by any of the
files included by the test program that configure is using. (Oddly,
although they are nominally not supported, vsnprintf() is used anyway in
the definition of git_vsnprintf().)
If I leave off any of the compilation options "-std=c89 -Wall -Werror"
or if I toggle the "#ifdef SNPRINTF_RETURNS_BOGUS" line in
git-compat-util.h off, the problem goes away.
2. The configure problem causes git_vsnprintf() to be wrapped around the
C library version. This leads to many failures in the test suite. I
suppose that git_vsnprintf() is broken in some way.
I'm kindof busy with my ref-api patch series so I won't have time to
look further into this problem in the near future. But perhaps somebody
with experience with the configuration system and/or git_vsnprintf() is
interested.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Jakub Narebski @ 2011-12-11 18:22 UTC (permalink / raw)
To: Gelonida N; +Cc: git, Sitaram Chamarty
In-Reply-To: <jc2l2a$som$1@dough.gmane.org>
Don't remove people from Cc, please.
Gelonida N <gelonida@gmail.com> writes:
> On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
> > On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
> > So what you want would boil down to this script (untested):
> >
> > #!/bin/bash
> > git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
> >
> > for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
> > do
> > git checkout $b
> > git merge --ff-only @{u}
> > done
>
> Is there no way to distinguish tracking branches from other branches?
> without checking them out?
>
> In order to save time I'd like to avoid checking out local branches.
You can use 'upstream' field name in git-for-each-ref invocation,
for example
git for-each-ref '--format=%(refname:short) %(upstream:short)' refs/heads |
grep -e ' [^ ]' |
sed -e 's/ .*$//
This could probably be done using only sed -- grep is not necessary.
> Ideally I would even like to avoid checking out branches, which don't
> need to be forwarded.
You can use git-update-ref plumbing, but you would have to do the
check if it does fast-forward yourself, and provide reflog message
yourself too.
Something like
git for-each-ref '--format=%(refname) %(upstream)' |
while read refname upstream
do
# there is upstream
test -n "$upstream" || break
# and if fast-forwards
test $(git merge-base $refname $upstream) = $(git rev-parse $refname) || break
git update-ref -m "$message" $refname $upstream
done
> I also had to remember on which branch I was in order to avoid, that I
> am at a random branch after running the script.
>
> I could imagine something like my snippet below , though I guess,
> there's something more elegant.
>
> git stash
> mybranch=`git branch | sed -n 's/\* *//p'`
> # do_script . . .
> git checkout $mybranch
> git stash apply
Don't use git-branch in scripting. See __git_ps1 function in
contrib/completion/git-completion.bash how it can be done:
b="$(git symbolic-ref HEAD 2>/dev/null)" ||
b="$(git rev-parse --verify HEAD)"
Nb. the second part is here only if there is possibility that you are
on detached HEAD (unnamed branch).
HTH (hope that helps)
--
Jakub Narębski
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Martin Langhoff @ 2011-12-11 16:27 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <jbvj5o$skt$1@dough.gmane.org>
On Sat, Dec 10, 2011 at 7:26 AM, Gelonida N <gelonida@gmail.com> wrote:
> What is the best way to fastforward all fastforwardable tracking
> branches after a git fetch?
It'd be a great addition to git fetch ;-)
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Gelonida N @ 2011-12-11 16:17 UTC (permalink / raw)
To: git
In-Reply-To: <20111211022218.GA22749@sita-lt.atc.tcs.com>
On 12/11/2011 03:22 AM, Sitaram Chamarty wrote:
> On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
>> Hi,
>>
>> What is the best way to fastforward all fastforwardable tracking
>> branches after a git fetch?
>
> I dont think there is a single command to do it for *all*
> branches, but for any particular branch, this should work:
A tiny script is fine. I didn't really expect the magic command.
Currently I'm using one script per repository, which hard coded the
branches,
that I want to fast-forward (checking them out and doing a git-pull)
>
> git merge --ff-only @{u}
>
Thanks, '--ff=only @{u}' is already the first improvement for my script.
> So what you want would boil down to this script (untested):
>
> #!/bin/bash
> git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
>
> for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
> do
> git checkout $b
> git merge --ff-only @{u}
> done
Is there no way to distinguish tracking branches from other branches?
without checking them out?
In order to save time I'd like to avoid checking out local branches.
Ideally I would even like to avoid checking out branches, which don't
need to be forwarded.
I also had to remember on which branch I was in order to avoid, that I
am at a random branch after running the script.
I could imagine something like my snippet below , though I guess,
there's something more elegant.
git stash
mybranch=`git branch | sed -n 's/\* *//p'`
# do_script . . .
git checkout $mybranch
git stash apply
^ permalink raw reply
* Re: Auto update submodules after merge and reset
From: Phil Hord @ 2011-12-11 14:43 UTC (permalink / raw)
To: Andreas T.Auer; +Cc: Jens Lehmann, git
In-Reply-To: <4EE2B8C3.6000906@ursus.ath.cx>
On Fri, Dec 9, 2011 at 8:41 PM, Andreas T.Auer
<andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:
>>> It is even nice to see which commits in the submodule belong to what
>>> branches in the superproject or to what release version (so tracking
>>> superproject tags would make sense, too). If you have a submodule that
>>> has
>>> more than one superproject but these are well-defined, it could be solved
>>> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for
>>> the
>>> other superproject), but currently I can't think of a context where this
>>> makes sense.
>>
>> I can, but this does put the cart before the horse. The submodule is
>> subservient to the super project in all my setups. The submodule is
>> not aware who owns him. He is a bit like the DAG in reverse. He
>> knows one direction only (children), not the other (parents).
>
> In the setup I have in mind, the submodules are not subservient to the
> superproject, but a part of the whole project.
I see that. I have a similar project with about 20 submodules. None
of them are useful on their own; they are logical divisions of a large
project.
Architecturally, submodules are oblivious of their super-projects in
all other respects. Changing the architectural underpinnings should
be a last resort, I think.
Phil
^ permalink raw reply
* Re: [PATCH 3/3] Rename resolve_ref() to resolve_ref_unsafe()
From: Nguyen Thai Ngoc Duy @ 2011-12-11 9:46 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano, Tony Wang
In-Reply-To: <20111210205519.GA24817@elie.hsd1.il.comcast.net>
2011/12/11 Jonathan Nieder <jrnieder@gmail.com>:
> Nguyễn Thái Ngọc Duy wrote:
>
>> resolve_ref() may return a pointer to a shared buffer and can be
>> overwritten by the next resolve_ref() calls. Callers need to
>> pay attention, not to keep the pointer when the next call happens.
> [...]
>> --- a/branch.c
>> +++ b/branch.c
>> @@ -182,7 +182,7 @@ int validate_new_branchname(const char *name, struct strbuf *ref,
>> const char *head;
>> unsigned char sha1[20];
>>
>> - head = resolve_ref("HEAD", sha1, 0, NULL);
>> + head = resolve_ref_unsafe("HEAD", sha1, 0, NULL);
>
> I wonder if it would make sense to have a separate function that
> maintains a shared buffer describing what HEAD resolves to, lazily
> loaded. Would invalidating the cache when appropriate be too fussy
> and subtle?
If we do not execute "git update-ref" from git binary (bisect does,
although on BISECT_HEAD, not HEAD) then it'd be safe to cache HEAD and
invalidate it in update_ref().
--
Duy
^ permalink raw reply
* Re: [PATCH 2/3] Guard memory overwriting in resolve_ref's static buffer
From: Nguyen Thai Ngoc Duy @ 2011-12-11 9:22 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano, Tony Wang
In-Reply-To: <20111210211040.GB24817@elie.hsd1.il.comcast.net>
2011/12/11 Jonathan Nieder <jrnieder@gmail.com>:
>> - Rely on mmap/mprotect to catch illegal access. We need valgrind or
>> some other memory tracking tool to reliably catch this in Michael's
>> approach.
>
> I wonder if the lower-tech approach would be so bad in practice. On
> systems using glibc, if MALLOC_PERTURB_ is set, then the value will
> always be clobbered on free(). It would be possible to do the same
> explicitly in resolve_ref() for platforms without such a feature.
Clobbered value may be carried around for some time before the code
detects wrong value. It'd be hard to track back where the root cause
is.
>> - Because mprotect is used instead of munmap, we definitely leak
>> memory. Hopefully callers will not put resolve_ref() in a
>> loop that runs 1 million times.
>
> Have you measured the performance impact when GIT_DEBUG_MEMCHECK is not
> set? (I don't expect major problems, but sometimes code surprises me.)
No. I wish we had a performance test suite. Which use cases should I test?
> [...]
>> Also introduce a new target, "make memcheck", that runs tests with this
>> flag on.
>
> Neat. Did it catch any bugs?
No, otherwise I would have sent more patches ;)
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -865,7 +865,8 @@ extern int read_ref(const char *filename, unsigned char *sha1);
>> *
>> * errno is sometimes set on errors, but not always.
>> */
>> -extern const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *flag);
>> +#define resolve_ref(ref, sha1, reading, flag) resolve_ref_real(ref, sha1, reading, flag, __FUNCTION__, __LINE__)
>
> __FUNCTION__ is nonstandard, though it's probably supported pretty
> widely and we can do
>
> #ifndef __FUNCTION__
> #define __FUNCTION__ something-else
> #endif
>
> in git-compat-util.h when we discover a platform that doesn't support
> it if needed. __func__ was introduced in C99. __LINE__ and __FILE__
> should work everywhere.
Will change to __FILE__ then
>> --- a/wrapper.c
>> +++ b/wrapper.c
>> @@ -60,6 +60,28 @@ void *xmallocz(size_t size)
>> return ret;
>> }
>>
>> +void *xmalloc_mmap(size_t size, const char *file, int line)
>> +{
>> + int *ret;
>> + size += sizeof(int*) * 3;
>> + ret = mmap(NULL, size, PROT_READ | PROT_WRITE,
>> + MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
>> + if (ret == (int*)-1)
>> + die_errno("unable to mmap %lu bytes anonymously",
>> + (unsigned long)size);
>> +
>> + ret[0] = (int)file;
>> + ret[1] = line;
>> + ret[2] = size;
>> + return ret + 3;
>
> Would this work on 64-bit platforms?
No idea (I'm on 32-bit). I don't see any reasons why it would not
work. But that function may cause unaligned access, I think.
> How does one retrieve the line and file number? I guess one is
> expected to retrieve them from the core dump, but a few words of
> advice in Documentation/technical would be helpful.
from coredump.
--
Duy
^ permalink raw reply
* Re: git for change control of software deployment updates
From: Neal Kreitzinger @ 2011-12-11 5:09 UTC (permalink / raw)
To: git
In-Reply-To: <CAJDDKr7+GeJTR986DSqKpQRWsXGFVzjBqg6WgRyG-EtycrQs7A@mail.gmail.com>
On 12/10/2011 9:19 PM, David Aguilar wrote:
> On Fri, Dec 9, 2011 at 6:37 PM, Neal Kreitzinger<neal@rsss.com> wrote:
>> I am considering using git with submodules to deploy most of our updates to
>> our customer linux servers (not including third party rpm updates already
>> tracked by linux distro rpm repository). Has anyone else done this?
>> Comments? (Sanity check.) (I am new to submodules.)
>
> I wrote a script that converts a git source repository into a redhat
> src.rpm. We use it at my $dayjob. How about doing something like
> that? After you have a src.rpm you can create rpms that you can
> distribute using yum. You are already using rpm which is why I
> mention it. Converting a directory of rpm files into a hostable
> repository is as simple as `createrepo /path/to/rpms/`.
>
> The git project has a 'make rpm' target in its Makefile that you could
> use as an example.
We use rhel so, yes, we use the redhat repo to get rhel patches. Is
that what you mean by "You are already using rpm"? (We do not write our
own rpm's at this time.)
v/r,
neal
^ permalink raw reply
* Re: git for change control of software deployment updates
From: David Aguilar @ 2011-12-11 3:19 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <jbugm2$afc$1@dough.gmane.org>
On Fri, Dec 9, 2011 at 6:37 PM, Neal Kreitzinger <neal@rsss.com> wrote:
> I am considering using git with submodules to deploy most of our updates to
> our customer linux servers (not including third party rpm updates already
> tracked by linux distro rpm repository). Has anyone else done this?
> Comments? (Sanity check.) (I am new to submodules.)
I wrote a script that converts a git source repository into a redhat
src.rpm. We use it at my $dayjob. How about doing something like
that? After you have a src.rpm you can create rpms that you can
distribute using yum. You are already using rpm which is why I
mention it. Converting a directory of rpm files into a hostable
repository is as simple as `createrepo /path/to/rpms/`.
The git project has a 'make rpm' target in its Makefile that you could
use as an example.
--
David
^ permalink raw reply
* Re: [PATCH] Copy resolve_ref() return value for longer use
From: Tony Wang @ 2011-12-11 2:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8Bg1=ESaZq8WQmZufsb6E8DY4RHqG0TWG-7uFX671zO6Q@mail.gmail.com>
Just notice that, thanks. :)
--
BR,
Tony Wang
On Saturday, December 10, 2011 at 12:48, Nguyen Thai Ngoc Duy wrote:
> On Sat, Dec 10, 2011 at 10:43 AM, Tony Wang <wwwjfy@gmail.com (mailto:wwwjfy@gmail.com)> wrote:
> > Hi,
> >
> > I don't know about the procedure, but wonder is any one following this?
>
> This series has been merged in master. I'll resend patches to rename
> resolve_ref() to resolve_ref_unsafe() soon.
> --
> Duy
^ permalink raw reply
* Re: best way to fastforward all tracking branches after a fetch
From: Sitaram Chamarty @ 2011-12-11 2:22 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <jbvj5o$skt$1@dough.gmane.org>
On Sat, Dec 10, 2011 at 01:26:32PM +0100, Gelonida N wrote:
> Hi,
>
> What is the best way to fastforward all fastforwardable tracking
> branches after a git fetch?
I dont think there is a single command to do it for *all*
branches, but for any particular branch, this should work:
git merge --ff-only @{u}
So what you want would boil down to this script (untested):
#!/bin/bash
git status --porcelain -uno | grep . && {echo dirty tree, exiting...; exit 1; }
for b in `git for-each-ref '--format=%(refname:short)' refs/heads`
do
git checkout $b
git merge --ff-only @{u}
done
^ 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