* [PATCH v2 00/51] ref-api-C and ref-api-D re-roll
From: mhagger @ 2011-12-12 5:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Drew Northup, Jakub Narebski, Heiko Voigt,
Johan Herland, Julian Phillips, Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
Following is a re-roll of the combination of the following patch
series:
ref-api-C == mh/ref-api-3 [1]
[PATCH v2 00/12] Use refs API more consistently
ref-api-D == mh/ref-api-take-2 [2]
[PATCH 00/28] Store references hierarchically in cache
ref-api-D-fix-v1 [3]
[PATCH] Fix "is_refname_available(): query only possibly-conflicting references"
It differs from the original patch series in the following ways:
* Re-rolled onto the current master.
* Combined some patches that logically belonged together but were
split in earlier series (mainly textual changes like variable
renamings); made other minor cleanups.
* Incorporated ref-api-D-fix-v1 into the commit that it was fixing.
* Removed any changes to the enforcement of refname checks. The
earlier patch series included some changes that slightly tightened
up the checks applied to refnames, and could therefore have
theoretically caused problems for people whose repositories
currently include invalid reference names. Following Junio's
suggestion, I separated those changes out of this patch series so
that they can be addressed separately.
Otherwise, this patch series includes the substance of the earlier
patch series, which is basically a change to storing reference-caches
hierarchically and reading loose references lazily. This, in turn,
brings big performance improvements for repositories with many
references (especially many loose references) [4].
[1] http://permalink.gmane.org/gmane.comp.version-control.git/184368
[2] http://permalink.gmane.org/gmane.comp.version-control.git/184382
[3] http://permalink.gmane.org/gmane.comp.version-control.git/185423
[4] http://permalink.gmane.org/gmane.comp.version-control.git/185541
Michael Haggerty (51):
struct ref_entry: document name member
refs: rename "refname" variables
refs: rename parameters result -> sha1
clear_ref_array(): rename from free_ref_array()
is_refname_available(): remove the "quiet" argument
parse_ref_line(): add docstring
add_ref(): add docstring
is_dup_ref(): extract function from sort_ref_array()
refs: change signatures of get_packed_refs() and get_loose_refs()
get_ref_dir(): change signature
resolve_gitlink_ref(): improve docstring
Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
resolve_gitlink_ref_recursive(): change to work with struct ref_cache
repack_without_ref(): remove temporary
create_ref_entry(): extract function from add_ref()
add_ref(): take a (struct ref_entry *) parameter
do_for_each_ref(): correctly terminate while processesing extra_refs
do_for_each_ref_in_array(): new function
do_for_each_ref_in_arrays(): new function
repack_without_ref(): reimplement using do_for_each_ref_in_array()
names_conflict(): new function, extracted from is_refname_available()
names_conflict(): simplify implementation
is_refname_available(): reimplement using do_for_each_ref_in_array()
refs.c: reorder definitions more logically
free_ref_entry(): new function
check_refname_component(): return 0 for zero-length components
struct ref_entry: nest the value part in a union
refs.c: rename ref_array -> ref_dir
refs: store references hierarchically
sort_ref_dir(): do not sort if already sorted
refs: sort ref_dirs lazily
do_for_each_ref(): only iterate over the subtree that was requested
get_ref_dir(): keep track of the current ref_dir
refs: wrap top-level ref_dirs in ref_entries
get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
is_refname_available(): take (ref_entry *) instead of (ref_dir *)
find_ref(): take (ref_entry *) instead of (ref_dir *)
read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
add_ref(): take (ref_entry *) instead of (ref_dir *)
find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
add_entry(): take (ref_entry *) instead of (ref_dir *)
do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
struct ref_dir: store a reference to the enclosing ref_cache
read_loose_refs(): take a (ref_entry *) as argument
refs: read loose references lazily
is_refname_available(): query only possibly-conflicting references
read_packed_refs(): keep track of the directory being worked in
repack_without_ref(): call clear_packed_ref_cache()
cache.h | 6 +-
refs.c | 1569 ++++++++++++++++++++++++++++++++++++++++----------------------
refs.h | 41 +-
3 files changed, 1041 insertions(+), 575 deletions(-)
--
1.7.8
^ permalink raw reply
* Re: [RFD] Handling of non-UTF8 data in gitweb
From: Junio C Hamano @ 2011-12-12 5:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Jürgen Kreileder, John Hawley
In-Reply-To: <201112101718.34848.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Wed, 7 Dec 2011, Junio C Hamano wrote:
>> I think we added and you acked 00f429a (gitweb: Handle non UTF-8 text
>> better, 2007-06-03) for a good reason, and I think the above argues that
>> whatever issue the commit tried to address is a non-issue. Is it really
>> true?
>
> I think that UTF-8 is much more prevalent character encoding in operating
> systems, programming languages, APIs, and software applications than it
> was 4 years ago.
Yeah, that was the kind of "reasoning behind it" explanation I was hoping
to see spelled out for people to agree or disagree.
But then the updated gitweb won't have trouble showing history of some
projects that has 4 yours or longer history (hopefully Git itself is not
among them).
> The proposed
>
> use open qw(:std :utf8);
>
> and removal of to_utf8 and $fallback_encoding would be regression compared
> to post-00f429a... but the tradeoff of more robust UTF-8 handling might be
> worth it.
>
>> > ... I guess
>> > it could be emulated by defining our own 'utf-8-with-fallback'
>> > encoding, or by defining our own PerlIO layer with PerlIO::via.
>> > But it no longer be simple solution (though still automatic).
>>
>> Between the current "everybody who read from the input must remember to
>> call to_utf8" and "everybody gets to read utf8 automatically for internal
>> processing", even though the latter may involve one-time pain to set up
>> the framework to do so, the pros-and-cons feels obvious to me.
>
> There is also a matter of performance (':utf8' and ':encoding(UTF-8)'
> are AFAIK implemented in C, both the Encode part and PerlIO part).
Would a reasonable first step be to replace the calls to bare "open" with
a wrapper that simulates the "open" interface (e.g. "sub git_open"), but
still keep the same behaviour as post-00f429a that could be much slower
than the native one? Then a separate patch can build a "regression but
uses native and much faster" alternative on top, no?
^ permalink raw reply
* [PATCH] Update documentation for stripspace
From: Conrad Irwin @ 2011-12-12 1:59 UTC (permalink / raw)
To: git; +Cc: Conrad Irwin
Tell the user what this command is intended for, and expand the
description of what it does.
Stop referring to the input as <stream>, as this command reads the
entire input into memory before processing it.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
Documentation/git-stripspace.txt | 26 ++++++++++++++++++++------
builtin/stripspace.c | 2 +-
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt
index b78f031..6667d25 100644
--- a/Documentation/git-stripspace.txt
+++ b/Documentation/git-stripspace.txt
@@ -3,26 +3,40 @@ git-stripspace(1)
NAME
----
-git-stripspace - Filter out empty lines
+git-stripspace - Remove unnecessary whitespace
SYNOPSIS
--------
[verse]
-'git stripspace' [-s | --strip-comments] < <stream>
+'git stripspace' [-s | --strip-comments] < input
DESCRIPTION
-----------
-Remove multiple empty lines, and empty lines at beginning and end.
+
+Normalizes input in the manner used by 'git' for user-provided metadata such
+as commit messages, notes, tags and branch descriptions.
+
+When run with no arguments this:
+
+- removes trailing whitespace from all lines
+- collapses multiple consecutive empty lines into one empty line
+- removes blank lines from the beginning and end of the input
+- ensures the last line ends with exactly one '\n'.
+
+In the case where the input consists entirely of whitespace characters, no
+output will be produced.
+
+*NOTE*: This is intended for cleaning metadata, prefer the `--whitespace=fix`
+mode of linkgit:git-apply[1] for correcting whitespace of patches or files in
+the repository.
OPTIONS
-------
-s::
--strip-comments::
- In addition to empty lines, also strip lines starting with '#'.
+ Also remove all lines starting with '#'.
-<stream>::
- Byte stream to act on.
GIT
---
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index 1288ffc..f16986c 100644
--- a/builtin/stripspace.c
+++ b/builtin/stripspace.c
@@ -75,7 +75,7 @@ int cmd_stripspace(int argc, const char **argv, const char *prefix)
!strcmp(argv[1], "--strip-comments")))
strip_comments = 1;
else if (argc > 1)
- usage("git stripspace [-s | --strip-comments] < <stream>");
+ usage("git stripspace [-s | --strip-comments] < input");
if (strbuf_read(&buf, 0, 1024) < 0)
die_errno("could not read the input");
--
1.7.8.164.g00d7e
^ permalink raw reply related
* 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
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