* Re: [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Johannes Sixt @ 2008-09-18 16:29 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Gavrilov, git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <20080918150238.GC21650@dpotapov.dyndns.org>
Dmitry Potapov schrieb:
> On Thu, Sep 18, 2008 at 01:07:32AM +0400, Alexander Gavrilov wrote:
>> The rationale for this is Windows support:
>>
>> 1) Windows people are accustomed to using legacy encodings
>> for text files. For many of them defaulting to utf-8
>> will be counter-intuitive.
>> 2) Windows doesn't support utf-8 locales, and switching
>> the system encoding is a real pain. Thus the option.
>
> I don't care much what is the default for Windows, but I wonder whether
> this rationale is good enough to change the default for other platforms.
"The default" should not be hardcoded in the tool.
By setting the encoding to "system", "the default" is taken from whatever
the system's current locale is. If you are on modern Linux, your locale is
most likely set to UTF8, and everything is fine; you won't observe a
change in behavior.
But if you are on a system whose locale was not set to UTF8, then you very
likely did *not* produce UTF8 data, and the display in git-gui was screwed
because it assumed UTF8. With this change it uses the system's encoding,
and it is an improvement.
> If you have systems configured with utf-8 and others (usually old ones)
> with legacy encoding, you will store files in utf-8 in your repo, thus
> having utf-8 as the default makes sense for non-Windows platforms.
How can you know? For example, I've to work with systems that use "legacy
encodings", and I can't use UTF8 in my data. Hence, the default of UTF8
was not exactly useful. With this patch series there's now a mechanism
that allows me to state the encoding per file, and all platforms should be
able to show the data in the correct way.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Anatol Pomozov @ 2008-09-18 16:31 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Junio C Hamano, Git Mailing List
In-Reply-To: <20080918092152.GA18732@coredump.intra.peff.net>
Hi, Jeff.
Thanks for your patch.
On Thu, Sep 18, 2008 at 2:21 AM, Jeff King <peff@peff.net> wrote:
> The "--root" option generally means "treat any commits
> without parents as a big creation event". This extends the
> meaning to make an index comparison against a non-existant
> HEAD into a big creation event. In other words, "if this
> index _were_ to become a commit, this is how we would show
> it with --root."
>
> Specifically, we cover the case of
>
> git diff --cached --root
>
> to show either the diff between the index and HEAD, or if
> there is no HEAD, show the diff against the empty tree.
> This can simplify calling scripts which must otherwise
> special-case the initial commit when showing the index
> status.
>
> We intentionally don't cover:
>
> - git diff --cached --root HEAD
>
> The user has specifically asked for HEAD, which doesn't
> exist.
>
> - git diff-index
>
> The user is required to specify a tree-ish to
> diff-index; if that tree-ish doesn't exist, we should
> report an error.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> On Tue, Sep 16, 2008 at 02:21:05AM -0400, Jeff King wrote:
>
>> Right, that was what I meant by "incomplete". I think there are several
>> other cases where giving "--root" would have expected behavior but is
>> currently ignored. I'll take a closer look, but I probably won't have
>> time for a few days.
>
> Actually, I wasn't able to find any more cases. I don't think it makes
> sense to override the behavior when an explicit tree-ish is given, so
> that cuts out the two places mentioned above. Though I think
> that scripts using this might prefer the plumbing
> diff-index, so maybe there is a better way to support this
> (e.g., if --root is specified without a tree-ish, assume
> HEAD or empty tree).
>
> diff-tree already handles --root itself. And there is no way to my
> knowledge to provoke the same kind of "show the diff against its parent"
> behavior via git-diff, since a single tree-ish there means "diff against
> the working tree".
>
> And of course for diff-files, such an option makes no sense.
>
> Can you think of any other cases?
git log??
git log --root for empty repo should not print anything (instead of
error message that we have now).
>
> builtin-diff.c | 7 +++++--
> revision.c | 17 ++++++++++++++---
> revision.h | 1 +
> t/t4030-diff-root.sh | 21 +++++++++++++++++++++
Should documentation (man-pages) reflect your changes as well?
> 4 files changed, 41 insertions(+), 5 deletions(-)
> create mode 100755 t/t4030-diff-root.sh
>
> diff --git a/builtin-diff.c b/builtin-diff.c
> index 037c303..0a1efb5 100644
> --- a/builtin-diff.c
> +++ b/builtin-diff.c
> @@ -315,8 +315,11 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
> break;
> else if (!strcmp(arg, "--cached")) {
> add_head_to_pending(&rev);
> - if (!rev.pending.nr)
> - die("No HEAD commit to compare with (yet)");
> + if (!rev.pending.nr) {
> + if (!rev.show_root_diff)
> + die("No HEAD commit to compare with (yet)");
> + add_empty_to_pending(&rev);
> + }
> break;
> }
> }
> diff --git a/revision.c b/revision.c
> index 499f0e0..de0fd89 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -145,16 +145,27 @@ void add_pending_object(struct rev_info *revs, struct object *obj, const char *n
> add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
> }
>
> -void add_head_to_pending(struct rev_info *revs)
> +static void add_to_pending_by_name(struct rev_info *revs, const char *name)
> {
> unsigned char sha1[20];
> struct object *obj;
> - if (get_sha1("HEAD", sha1))
> + if (get_sha1(name, sha1))
> return;
> obj = parse_object(sha1);
> if (!obj)
> return;
> - add_pending_object(revs, obj, "HEAD");
> + add_pending_object(revs, obj, name);
> +}
> +
> +void add_head_to_pending(struct rev_info *revs)
> +{
> + add_to_pending_by_name(revs, "HEAD");
> +}
> +
> +void add_empty_to_pending(struct rev_info *revs)
> +{
> + add_to_pending_by_name(revs,
> + "4b825dc642cb6eb9a060e54bf8d69288fbee4904");
> }
>
> static struct object *get_reference(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags)
> diff --git a/revision.h b/revision.h
> index fc23522..108f43d 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -151,6 +151,7 @@ extern void add_object(struct object *obj,
> extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name);
>
> extern void add_head_to_pending(struct rev_info *);
> +extern void add_empty_to_pending(struct rev_info *);
>
> enum commit_action {
> commit_ignore,
> diff --git a/t/t4030-diff-root.sh b/t/t4030-diff-root.sh
> new file mode 100755
> index 0000000..e5174b7
> --- /dev/null
> +++ b/t/t4030-diff-root.sh
> @@ -0,0 +1,21 @@
> +#!/bin/sh
> +
> +test_description='diff --root allows comparison between index and root'
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> + echo content >file &&
> + git add file
> +'
> +
> +test_expect_success 'diff --cached (without --root)' '
> + test_must_fail git diff --cached --name-only
> +'
> +
> +test_expect_success 'diff --cached (with --root)' '
> + echo file >expect &&
> + git diff --cached --name-only --root >actual &&
> + test_cmp expect actual
> +'
> +
> +test_done
> --
> 1.6.0.2.249.g97d7f.dirty
--
anatol
^ permalink raw reply
* Re: How to supply "raw" bytes to git grep?
From: Jakub Narebski @ 2008-09-18 16:31 UTC (permalink / raw)
To: git
In-Reply-To: <200809181728.18597.johan@herland.net>
Johan Herland wrote:
> I wanted to list all text files in my repo which contain carriage
> returns, so I tried the following command-line:
>
> git grep --cached -I -l -e <CR>
>
> where <CR> is some magic incantation that I've yet to figure out. I've
> tried all the obvious cases (\r, 0x0d, \015, etc.), but none of them
> seem to DWIM...
Why not use _literal_ CR; of course protecting it by piockung it by
shell as end of command by quites, for example
$ git grep --cached -I -l -e '
'
It works for me (bash).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Help breaking up a large merge.
From: Johannes Sixt @ 2008-09-18 16:41 UTC (permalink / raw)
To: David Brown; +Cc: Git Mailing List
In-Reply-To: <20080918152154.GA27019@linode.davidb.org>
David Brown schrieb:
> Say we have a tree that we've been working on for a few months. An
> outside vendor has also been working on the same tree during this
> time, and we need to merge with their work.
>
> The difficulty I'm having is that there are a lot of conflicts
> resulting from the merge (expected), and it would be nice to somehow
> be able to work on a smaller set of these conflicts at a time.
>
> Some of the conflicts are caused by a single change in the other tree.
> This is easy to cherry-pick into my tree, resolve, and then test those
> changes independently.
>
> But other conflicts are caused by groups of commits that are
> interleaved with others.
In a similar situation I was thinking about this approach:
1. Do the merge.
2. Resolve conflicts in an area that can be tested in isolation.
3. Undo all other changes that the merge brought in.
4. Commit.
5. Install a graft that removes the second parent of the merge commit.
6. Rinse and repeat.
7. Finally, remove the grafts, and perhaps collapse the merge commits.
I didn't test this, yet.
Hmm, thinking a bit more about this, 1 and 5 can probably be replaced by a
mere 'git merge --squash'.
-- Hannes
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Dmitry Potapov @ 2008-09-18 16:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alexander Gavrilov, git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <48D281E6.1070204@viscovery.net>
On Thu, Sep 18, 2008 at 06:29:26PM +0200, Johannes Sixt wrote:
>
> By setting the encoding to "system", "the default" is taken from whatever
> the system's current locale is. If you are on modern Linux, your locale is
> most likely set to UTF8, and everything is fine; you won't observe a
> change in behavior.
That's right.
> But if you are on a system whose locale was not set to UTF8, then you very
> likely did *not* produce UTF8 data, and the display in git-gui was screwed
> because it assumed UTF8. With this change it uses the system's encoding,
> and it is an improvement.
It is not about how data are stored locale but what is in repository.
Even if you still have some Linux box with legacy encoding on it, you
still want to see what in repository, which is mostly likely to be in
UTF-8. Even if you do not have UTF-8 locale, all decent editors are
capable to read and store files in UTF-8 (even if it is not your locale),
and it is really make sense to store files in UTF-8, which makes sense
because you are going then on a modern Linux, you want to have all data
in the repository to be in a single encoding, and UTF-8 is the best
choice for that.
>
> > If you have systems configured with utf-8 and others (usually old ones)
> > with legacy encoding, you will store files in utf-8 in your repo, thus
> > having utf-8 as the default makes sense for non-Windows platforms.
>
> How can you know? For example, I've to work with systems that use "legacy
> encodings", and I can't use UTF8 in my data. Hence, the default of UTF8
> was not exactly useful. With this patch series there's now a mechanism
> that allows me to state the encoding per file, and all platforms should be
> able to show the data in the correct way.
This patch is certainly a big improvement, as it allows to choose what
encoding you want to see, but I was not sure that changing the default
from UTF-8 to the system locale is really a good idea for anything but
Windows specific projects. Anyway, I have converted all computers that
I use regularly to UTF-8, so I don't really care...
Dmitry
^ permalink raw reply
* Re: [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Sverre Rabbelier @ 2008-09-18 16:51 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: Jeff King, Junio C Hamano, Git Mailing List
In-Reply-To: <3665a1a00809180931t191b5a24wd58554cdb761535@mail.gmail.com>
[Please cull the parts of the mail you are not responding to, it is
hard to find your reply when you don't.]
On Thu, Sep 18, 2008 at 18:31, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
> git log??
>
> git log --root for empty repo should not print anything (instead of
> error message that we have now).
I do not agree here, what is the use in having a command that does nothing?
> Should documentation (man-pages) reflect your changes as well?
Yes, they should be updated.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Alexander Gavrilov @ 2008-09-18 17:00 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Sixt, git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <20080918165032.GD21650@dpotapov.dyndns.org>
On Thu, Sep 18, 2008 at 8:50 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> It is not about how data are stored locale but what is in repository.
> Even if you still have some Linux box with legacy encoding on it, you
> still want to see what in repository, which is mostly likely to be in
> UTF-8. Even if you do not have UTF-8 locale, all decent editors are
> capable to read and store files in UTF-8 (even if it is not your locale),
> and it is really make sense to store files in UTF-8, which makes sense
> because you are going then on a modern Linux, you want to have all data
> in the repository to be in a single encoding, and UTF-8 is the best
> choice for that.
A new user would expect to see his files properly, and they are likely
to be in the locale encoding. And if you know about utf-8, you can
open the Options dialog, and select it explicitly from a menu. And if
you commit a .gitattributes file with encoding specifications to the
repository, it will be used automatically wherever you check it out.
> This patch is certainly a big improvement, as it allows to choose what
> encoding you want to see, but I was not sure that changing the default
> from UTF-8 to the system locale is really a good idea for anything but
> Windows specific projects. Anyway, I have converted all computers that
> I use regularly to UTF-8, so I don't really care...
You are here missing the fact, that the actual current default for
git-gui is not utf-8, but 'binary', essentially equivalent to
ISO-8859-1. UTF-8 was suggested by a patch that has been around in the
'pu' branch since January, and which I took as a base for my series.
Gitk on the other hand uses the locale encoding.
Alexander
^ permalink raw reply
* [TopGit PATCH] .gitignore += vim swap files
From: Kirill Smelkov @ 2008-09-18 16:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Kirill Smelkov
In-Reply-To: <1221755370-6817-1-git-send-email-kirr@landau.phys.spbu.ru>
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
.gitignore | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 8868f2d..aa39db4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,3 +18,5 @@ tg-import.txt
tg-remote
tg-remote.txt
tg
+
+*.swp
--
1.6.0.2.250.g965aa
^ permalink raw reply related
* [TopGit PATCH] tg import: fix + make more robust
From: Kirill Smelkov @ 2008-09-18 16:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Kirill Smelkov
In-Reply-To: <1221755370-6817-1-git-send-email-kirr@landau.phys.spbu.ru>
a5bf892d0900cbf9949f628c3e05db599341a02c (tg import: Check out new files
as we go) broke tg-import. This is how it fails after that change:
$ tg import Z~~..Z
tg: ---- Importing e3e8c1382fe4cedca31e955910914ae0033455eb to t/Z
tg: Automatically marking dependency on master
tg: Creating t/Z base from master...
Switched to a new branch "t/Z"
tg: Topic branch t/Z set up. Please fill .topmsg now and make initial commit.
tg: To abort: git rm -f .top* && git checkout master && tg delete t/Z
fatal: pathspec '.topdeps' did not match any files
That's why, when we do git read-tree -u -m it _kills_ .topmsg and
.topdep both in index and in working tree!
Also, imagine that we are going to import patch C onto A
o---B---A
\
C
With read-tree we'll *override* any change in common files between A and
B, so I think read-tree is wrong here (it was ok if we are importing
on top of B).
What is right it seems, is to work on diff level -- to use cherry-pick.
And since cherry-pick does not kill our already-in-index .topmsg and
.topdeps we automatically fix the breakage.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
tg-import.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg-import.sh b/tg-import.sh
index 68477f0..799efc9 100644
--- a/tg-import.sh
+++ b/tg-import.sh
@@ -61,7 +61,7 @@ process_commit()
branch_name=$(get_branch_name "$commit")
info "---- Importing $commit to $branch_prefix$branch_name"
tg create "$branch_prefix""$branch_name"
- git read-tree -u -m "$commit"
+ git cherry-pick --no-commit "$commit"
get_commit_msg "$commit" > .topmsg
git add -f .topmsg .topdeps
git commit -C "$commit"
--
1.6.0.2.250.g965aa
^ permalink raw reply related
* A couple of TopGit tweaks
From: Kirill Smelkov @ 2008-09-18 16:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
Hi,
I'm still learning tg, but in the process I've tweaked 'tg help' for
good and fixed 'tg import'.
Please apply.
^ permalink raw reply
* [TopGit PATCH] tg help: <something>: improve readability
From: Kirill Smelkov @ 2008-09-18 16:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Kirill Smelkov
In-Reply-To: <1221755370-6817-1-git-send-email-kirr@landau.phys.spbu.ru>
Previously tg help was not showing Usage line, and with this change, now it
looks like e.g.:
$ tg help import
Usage: tg [...] import [-p PREFIX] RANGE...
Import commits within the given revision range into TopGit,
creating one topic branch per commit, the dependencies forming
a linear sequence starting on your current branch.
The branch names are auto-guessed from the commit messages
and prefixed by t/ by default; use '-p PREFIX' to specify
an alternative prefix (even an empty one).
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
tg.sh | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/tg.sh b/tg.sh
index 545e1b8..08975ae 100644
--- a/tg.sh
+++ b/tg.sh
@@ -224,8 +224,12 @@ do_help()
echo "TopGit v0.3 - A different patch queue manager"
echo "Usage: tg [-r REMOTE] ($cmds|help) ..."
- elif [ -r "@sharedir@/tg-$1.txt" ] ; then
- cat "@sharedir@/tg-$1.txt"
+ elif [ -r "@cmddir@"/tg-$1 ] ; then
+ @cmddir@/tg-$1 -h || :
+ echo
+ if [ -r "@sharedir@/tg-$1.txt" ] ; then
+ cat "@sharedir@/tg-$1.txt"
+ fi
else
echo "`basename $0`: no help for $1" 1>&2
fi
--
1.6.0.2.250.g965aa
^ permalink raw reply related
* Re: [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Dmitry Potapov @ 2008-09-18 17:19 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Johannes Sixt, git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <bb6f213e0809181000l52c55e8ctdfa49a59002e60cf@mail.gmail.com>
On Thu, Sep 18, 2008 at 09:00:07PM +0400, Alexander Gavrilov wrote:
>
> You are here missing the fact, that the actual current default for
> git-gui is not utf-8, but 'binary', essentially equivalent to
> ISO-8859-1.
In this case, I was just confused by the comment to the patch, which was
saying "Make diffs and blame default to the system (locale) encoding
instead of hard-coding UTF-8."
> UTF-8 was suggested by a patch that has been around in the
> 'pu' branch since January, and which I took as a base for my series.
> Gitk on the other hand uses the locale encoding.
I see... Then your patch makes perfect sense regardless of Windows
support, which was presented as the rationale for the patch.
Thanks,
Dmitry
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: martin f krafft @ 2008-09-18 17:24 UTC (permalink / raw)
To: Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <1221755370-6817-2-git-send-email-kirr@landau.phys.spbu.ru>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2008.09.18.1729 +0100]:
> +
> +*.swp
This should be .*.sw?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"and no one sings me lullabies,
and no one makes me close my eyes,
and so i throw the windows wide,
and call to you across the sky"
-- pink floyd, 1971
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Kirill Smelkov @ 2008-09-18 17:30 UTC (permalink / raw)
To: martin f krafft; +Cc: Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <20080918172418.GA28942@lapse.rw.madduck.net>
On Thu, Sep 18, 2008 at 06:24:18PM +0100, martin f krafft wrote:
> also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2008.09.18.1729 +0100]:
> > +
> > +*.swp
>
> This should be .*.sw?
Right.
Should I resend the patch or will Petr correct it when applying?
--
Всего хорошего, Кирилл.
^ permalink raw reply
* Re: Help breaking up a large merge.
From: Avery Pennarun @ 2008-09-18 17:40 UTC (permalink / raw)
To: David Brown; +Cc: Git Mailing List
In-Reply-To: <20080918152154.GA27019@linode.davidb.org>
On Thu, Sep 18, 2008 at 11:21 AM, David Brown <git@davidb.org> wrote:
> The difficulty I'm having is that there are a lot of conflicts
> resulting from the merge (expected), and it would be nice to somehow
> be able to work on a smaller set of these conflicts at a time.
>
> Some of the conflicts are caused by a single change in the other tree.
> This is easy to cherry-pick into my tree, resolve, and then test those
> changes independently.
I've had the same sort of problem at work and I've gone through
several iterations trying to solve a problem. The short version is
that all the solutions proposed here so far, plus some other ones I
thought of, don't seem to cut down the work for me :)
But here's one that has helped quite a bit, assuming that breaking up
the merge by *files* makes sense.
...
Let's say you have two branches, A and B, derived from a base X. We
want to merge the branch with fewer changes on top of the branch with
more changes, because it'll be less work to divide up :) Let's assume
the branch with fewer changes is A.
1) Generate a giant patch file using 'git diff X..A'. Call the patch P.
2) Using an editor, divide up the patch by files/subdirs based on how
you want to subdivide the work. Or alternatively, do that with 'git
diff' itself, but beware of accidentally forgetting to ask for some
files if you do it that way. Call these n individual patches P1..Pn.
3) Create new branches called A1..An, copied directly from X.
4) Apply each patch P1..Pn to each branch A1..An. (They will all
apply cleanly, because they are all patches against X in the first
place.)
5) Create new branches called B1..Bn, copied directly from *B*.
6) 'git merge' A1 into B1, A2 into B2, and so on. Resolve the conflicts.
7) Create a new branch, TEST, copied from B. Do an octopus merge from
B1..Bn. There will be no conflicts, because those branches all make
mutually exclusive changes, and they're all based on B. You now have
a combined branch containing A+B, but the history from A is missing.
8) Create a new patch, PFINAL, using 'git diff B..TEST'. This is the
complete set of changes to turn B into A+B.
9) Checkout B. 'git merge A'; there will be conflicts. 'git checkout
HEAD .' to go back to B's files. Patch in PFINAL, and commit.
Now you have a single merge commit with all the changes, and the
history will be correct.
10) Optional: 'git merge B1..Bn' so that you don't lose the history of
the individual sub-merges (you might want to look at them later or use
them for blame purposes). There shouldn't be any conflicts, as the
changes in those branches are identical to the changes you just
committed, and git will discard them in the extra merge.
10b) Optional advanced-only trick: amend the main commit so that it
looks like an octopus merge of B, A, and B1..Bn, instead of having a
separate fake merge commit.
Note that this also helps a lot (for me) even if it's just a single
person doing the merge: I like to do the library changes first, get
all the library unit tests passing, then move up to bigger and bigger
components.
Hope this helps.
Have fun,
Avery
^ permalink raw reply
* Re: Help breaking up a large merge.
From: David Brown @ 2008-09-18 17:47 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b130809181040p4785f877s7502c578e46745d8@mail.gmail.com>
On Thu, Sep 18, 2008 at 01:40:55PM -0400, Avery Pennarun wrote:
>1) Generate a giant patch file using 'git diff X..A'. Call the patch P.
>
>2) Using an editor, divide up the patch by files/subdirs based on how
>you want to subdivide the work. Or alternatively, do that with 'git
>diff' itself, but beware of accidentally forgetting to ask for some
>files if you do it that way. Call these n individual patches P1..Pn.
The is fairly close to the approach I've been taking, but somehow I
didn't think of using the output of diff itself and hacking that up.
I like this because it makes it easier to not forget some files.
It is likely there will be makefiles to cleanup and such, but
otherwise I like this idea.
Thanks,
David
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Bert Wesarg @ 2008-09-18 17:38 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <1221755370-6817-2-git-send-email-kirr@landau.phys.spbu.ru>
On Thu, Sep 18, 2008 at 18:29, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> ---
> .gitignore | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 8868f2d..aa39db4 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -18,3 +18,5 @@ tg-import.txt
> tg-remote
> tg-remote.txt
> tg
> +
> +*.swp
can't you do this in your .git/info/excludes?
bert
> --
> 1.6.0.2.250.g965aa
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Kirill Smelkov @ 2008-09-18 17:43 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <36ca99e90809181038o74c73121j59849b3f24fe6469@mail.gmail.com>
On Thu, Sep 18, 2008 at 07:38:58PM +0200, Bert Wesarg wrote:
> On Thu, Sep 18, 2008 at 18:29, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> > Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> > ---
> > .gitignore | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 8868f2d..aa39db4 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -18,3 +18,5 @@ tg-import.txt
> > tg-remote
> > tg-remote.txt
> > tg
> > +
> > +*.swp
> can't you do this in your .git/info/excludes?
>
> bert
I sure can, but I think the question is what is the most convenient, and
for me it is convenient to start hacking right on fresh topgit clone.
Also, if you'll look e.g. here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=.gitignore;h=869e1a3b64b6bf969eeced820691e955e03e3068;hb=HEAD#l65
It seems emacs is supported in Linux kernel, so I'm slowly restoring the
balance in favour of vim :)
--
Всего хорошего, Кирилл.
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: martin f krafft @ 2008-09-18 17:54 UTC (permalink / raw)
To: Bert Wesarg, Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <36ca99e90809181038o74c73121j59849b3f24fe6469@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.09.18.1838 +0100]:
> can't you do this in your .git/info/excludes?
Of course, but then I'd have to do it too, and on all machines where
I have a topgit clone.
martin, who'd love to see '/*-stamp' added to the .gitignore file
too to hide the temporary files created during the Debian build;
mdadm recently added it. :)
--
martin | http://madduck.net/ | http://two.sentenc.es/
"in diving to the bottom of pleasure
we bring up more gravel than pearls."
-- honoré de balzac
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Bert Wesarg @ 2008-09-18 17:56 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <20080918174307.GL11602@roro3>
On Thu, Sep 18, 2008 at 19:43, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> On Thu, Sep 18, 2008 at 07:38:58PM +0200, Bert Wesarg wrote:
>> On Thu, Sep 18, 2008 at 18:29, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
>> > Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
>> > ---
>> > .gitignore | 2 ++
>> > 1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/.gitignore b/.gitignore
>> > index 8868f2d..aa39db4 100644
>> > --- a/.gitignore
>> > +++ b/.gitignore
>> > @@ -18,3 +18,5 @@ tg-import.txt
>> > tg-remote
>> > tg-remote.txt
>> > tg
>> > +
>> > +*.swp
>> can't you do this in your .git/info/excludes?
>>
>> bert
>
> I sure can, but I think the question is what is the most convenient, and
> for me it is convenient to start hacking right on fresh topgit clone.
>
>
> Also, if you'll look e.g. here:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=.gitignore;h=869e1a3b64b6bf969eeced820691e955e03e3068;hb=HEAD#l65
>
> It seems emacs is supported in Linux kernel, so I'm slowly restoring the
> balance in favour of vim :)
than I want a pattern for NEdit too:
~*
Bert
>
> --
> Всего хорошего, Кирилл.
>
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Kirill Smelkov @ 2008-09-18 17:50 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <36ca99e90809181056i534cffc8td8095140db4949bf@mail.gmail.com>
On Thu, Sep 18, 2008 at 07:56:40PM +0200, Bert Wesarg wrote:
> On Thu, Sep 18, 2008 at 19:43, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> > On Thu, Sep 18, 2008 at 07:38:58PM +0200, Bert Wesarg wrote:
> >> On Thu, Sep 18, 2008 at 18:29, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> >> > Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> >> > ---
> >> > .gitignore | 2 ++
> >> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/.gitignore b/.gitignore
> >> > index 8868f2d..aa39db4 100644
> >> > --- a/.gitignore
> >> > +++ b/.gitignore
> >> > @@ -18,3 +18,5 @@ tg-import.txt
> >> > tg-remote
> >> > tg-remote.txt
> >> > tg
> >> > +
> >> > +*.swp
> >> can't you do this in your .git/info/excludes?
> >>
> >> bert
> >
> > I sure can, but I think the question is what is the most convenient, and
> > for me it is convenient to start hacking right on fresh topgit clone.
> >
> >
> > Also, if you'll look e.g. here:
> >
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=.gitignore;h=869e1a3b64b6bf969eeced820691e955e03e3068;hb=HEAD#l65
> >
> > It seems emacs is supported in Linux kernel, so I'm slowly restoring the
> > balance in favour of vim :)
> than I want a pattern for NEdit too:
>
> ~*
I'm not against :)
--
Всего хорошего, Кирилл.
^ permalink raw reply
* Re: [PATCH] Documentation: warn against merging in a dirty tree
From: Avery Pennarun @ 2008-09-18 18:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Thomas Rast, git, Jakub Narebski, Miklos Vajna
In-Reply-To: <alpine.LFD.1.10.0809180804100.3337@nehalem.linux-foundation.org>
On Thu, Sep 18, 2008 at 11:15 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, 15 Sep 2008, Avery Pennarun wrote:
>>
>> But how do you abort a *failed* merge in a situation like Linus's
>> example? "git reset --hard HEAD" would destroy the unstaged Makefile
>> change.
>
> As mentioned by others, sometimes you are simply willing to take the risk.
> If I have dirty data, I still want to merge, because (a) my dirty data is
> a _convenience_ and (b) the risk of me having to do a "git reset" is
> pretty low anyway.
In that case, my next question is how you pull off (b), because that's
*way* better than just being able to undo when I get myself into
trouble :) I do and then reset test merges all the time.
> That said, it's actually kind of sad that we don't expose a real
> capability that the git plumbing does have. Namely
>
> git read-tree -u -m HEAD ORIG_HEAD
>
> should do the right thing if you want to undo a merge (except it doesn't
> actually write ORIG_HEAD to be the new head: you could use "git reset"
> with --soft to do that, or just git update-ref).
Hmm,
$ git read-tree -u -m HEAD ORIG_HEAD
fatal: you need to resolve your current index first
It appears that the above would be great for undoing a
*non*conflicting merge, but that's not as important ;)
> So it _may_ be that something like
>
> [alias]
> undo = !git read-tree -u -m HEAD ORIG_HEAD && git reset --soft ORIG_HEAD
>
> would actually give you "git undo".
>
> So we have the technology, and we just don't _expose_ that capability as a
> "git reset" thing. And we probably should. In fact, that is often the
> thing people really want, and it would have made sense to have it as the
> default action, but the initial design for "git reset" was literally as a
> way to get you out of a sticky corner when you had unmerged entries and
> you just wanted to throw away crud.
Note that if we were going to do an undo, it would be nice to be
careful about allowing multiple consecutive undos. "git undo; git
undo;" shouldn't be a no-op, it should undo two things. At least,
that's how the rest of the world (okay, my text editor) works. "git
redo" could be the opposite of "git undo".
I imagine some trick using the reflog would thus be better here than
updating ORIG_HEAD.
Since that's a lot of work, I'd propose having a first pass at the
undo operation use ORIG_HEAD and then just delete or rename ORIG_HEAD,
so that 'git undo; git undo' is meaningless.
Have fun,
Avery
^ permalink raw reply
* Re: failure doing massive revert
From: Avery Pennarun @ 2008-09-18 18:26 UTC (permalink / raw)
To: Mike Galbraith; +Cc: git
In-Reply-To: <1221728946.8516.14.camel@marge.simson.net>
On Thu, Sep 18, 2008 at 5:09 AM, Mike Galbraith <efault@gmx.de> wrote:
> For reasons I'd rather not go into, I decided to create a merge free
> tree to try to bisect. I did this yesterday for a smaller range, and it
> worked fine, and I was able to revert the reverts to re-apply. Trying
> to revert everything from v2.6.26..today croaked.
>
> for i in `git rev-list --no-merges v2.6.26..HEAD`; do git revert $i < /dev/null; done
Hmm, I don't think you can revert every single patch on a merged tree
that way for the same reason you can't just rebase it: history wasn't
linear.
I think something involving 'git rev-list --first-parent' and some
variant of "git diff $i $i^ | git apply" might work better, as it
would inherently squash merge commits, thus making them linearly
reversible (although throwing away large parts of history).
Throwing away history might not be what you want, but then again,
maybe it is. It's the only way I know of to 100% reliably linearize
the history, anyway.
Also, if you use "&& done" instead of "; done" then it'll abort right
away when it has a problem.
Have fun,
Avery
^ permalink raw reply
* Re: [TopGit PATCH] .gitignore += vim swap files
From: Daniel Barkalow @ 2008-09-18 19:30 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Kirill Smelkov, Petr Baudis, Git Mailing List
In-Reply-To: <36ca99e90809181038o74c73121j59849b3f24fe6469@mail.gmail.com>
On Thu, 18 Sep 2008, Bert Wesarg wrote:
> On Thu, Sep 18, 2008 at 18:29, Kirill Smelkov <kirr@landau.phys.spbu.ru> wrote:
> > Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> > ---
> > .gitignore | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 8868f2d..aa39db4 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -18,3 +18,5 @@ tg-import.txt
> > tg-remote
> > tg-remote.txt
> > tg
> > +
> > +*.swp
> can't you do this in your .git/info/excludes?
It's generally better to put a core.excludesfile entry in your
~/.gitconfig pointing to a ignore file with editor temporaries for the
editor(s) you personally use. This will then apply to all git projects you
work on.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 0/1] Add new test to demonstrate git archive core.autocrlf inconsistency
From: Charles Bailey @ 2008-09-18 20:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
t/t0024-crlf-archive.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100644 t/t0024-crlf-archive.sh
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
new file mode 100644
index 0000000..3511439
--- /dev/null
+++ b/t/t0024-crlf-archive.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='respect crlf in git archive'
+
+. ./test-lib.sh
+UNZIP=${UNZIP:-unzip}
+
+test_expect_success setup '
+
+ git config core.autocrlf true
+
+ printf "CRLF line ending\r\nAnd another\r\n" > sample &&
+ git add sample &&
+
+ test_tick &&
+ git commit -m Initial
+
+'
+
+test_expect_success 'tar archive' '
+
+ git archive --format=tar HEAD |
+ ( mkdir untarred && cd untarred && "$TAR" -xf - )
+
+ test_cmp sample untarred/sample
+
+'
+
+"$UNZIP" -v >/dev/null 2>&1
+if [ $? -eq 127 ]; then
+ echo "Skipping ZIP test, because unzip was not found"
+ test_done
+ exit
+fi
+
+test_expect_failure 'zip archive' '
+
+ git archive --format=zip HEAD >test.zip &&
+
+ ( mkdir unzipped && cd unzipped && unzip ../test.zip ) &&
+
+ test_cmp sample unzipped/sample
+
+'
+
+test_done
--
1.6.0.1.309.g4f56
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply related
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