* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Junio C Hamano @ 2010-01-06 1:06 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List,
Johannes Schindelin
In-Reply-To: <20100101090550.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> Makefile improvements. No discussion.
I was mildly interested in the series, but after this:
http://thread.gmane.org/gmane.comp.version-control.git/133872/focus=133911
the progress seems to have stopped.
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Junio C Hamano @ 2010-01-06 1:06 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4B43AE38.9070800@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Junio C Hamano schrieb:
>> After you find out an earlier resolution you told rerere to use was a
>> mismerge, there is no easy way to clear it. A new subcommand "forget" can
>> be used to tell git to forget a recorded resolution, so that you can redo
>> the merge from scratch.
>> ...
>> diff --git a/rerere.c b/rerere.c
>> index f013ae7..c1da6f6 100644
>> --- a/rerere.c
>> +++ b/rerere.c
>> ...
>> +static int handle_cache(const char *path, unsigned char *sha1)
>> +{
>> +...
>> + ll_merge(&result, path, &mmfile[0],
>> + &mmfile[1], "ours",
>> + &mmfile[2], "theirs", 0);
>
> When you simply call ll_merge(), will it obey any merge drivers that
> are defined in .gitattributes? Do we care about them?
>
> I already had an implementation of "rerere forget" before you
> presented this solution, but it relies on that the user calls
> "checkout --conflict=merge" first. One reason (besides its simplicity)
> was that it does not have to care how the merge is computed.
Doesn't "checkout --conflict=merge" use the same ll_merge() machinery?
> [I haven't submitted my solution, yet, because I haven't had the time
> to do this large merge where I expect to make use "rerere forget",
> testing its usefulness.]
>
> -- Hannes
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Junio C Hamano @ 2010-01-06 1:04 UTC (permalink / raw)
To: Jens Lehmann
Cc: Johannes Schindelin, Git Mailing List, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <4B439A86.3020500@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 05.01.2010 19:31, schrieb Junio C Hamano:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>> b) new unignored files
>>> IMO these files should show up too (the superproject doesn't show
>>> ignored files, the submodule state shouldn't do that either). But
>>> OTOH i don't see a possibility for loss of data when this state is
>>> not shown.
>>
>> I don't know if we are talking about the same scenario. What I had in
>> mind was:
>>
>> cd sub
>> edit new-file
>> tests ok and be happy
>> git commit
>> cd ..
>> git status
>> git commit
>>
>> forgetting that only you have sub/new-file in the world. It is not loss
>> of data, but still bad. Forgetting to add a new-file and committing in a
>> project without submodule doesn't lose data, but the resulting commit will
>> be seen as broken by other people.
>
> I'm not quite sure, i was rather thinking about something like this:
>
> cd sub
> edit new-file
> cd ..
> <use sub/new-file here, test ok and be happy>
> git status
> git commit
> git push
>
> git status won't show you that sub has any new files and so you won't be
> reminded that you still have to add, commit and push it in the submodule
> before you should even commit, let alone push in the superproject.
>
> It is a possible breakage for other people if sub/new-file stays unnoticed.
> That's IMO a good point for showing these files too.
Yeah, your "i don't see a possibility for lost of data when this state is
not shown" confused me into thinking as if you were saying it is not _too_
bad if we didn't show the information.
After all we _were_ in agreement. We both think the user should be told
about untracked files in submodule directory when inspecting the status to
make a commit in the superproject.
^ permalink raw reply
* Re: [PATCH v3 2/6] t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
From: Junio C Hamano @ 2010-01-06 1:04 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Daniel Barkalow, Jeff King, Junio C Hamano
In-Reply-To: <20091224154158.15ba580f.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> Test that when non-fast-forwarded refs cannot be matched without an
> explicit refspect, the push fails with a non-fast-forward ref status and
> help message.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
> t/t5541-http-push.sh | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
> index f49c7c4..5ebe04a 100755
> --- a/t/t5541-http-push.sh
> +++ b/t/t5541-http-push.sh
> @@ -111,5 +111,25 @@ Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
> section of '"'git push --help'"' for details." output
> '
>
> +test_expect_failure 'push fails for non-fast-forward refs unmatched by remote helper' '
> + # create a dissimilarly-named ref so that git is unable to match the refs
> + git push origin master:retsam
> +
> + echo "change changed" > path2 &&
> + git commit -a -m path2 --amend &&
> +
> + # push master too. This ensures there is at least one '"'push'"' command to
> + # the remote helper and triggers interaction with the helper.
> + !(git push -v origin +master master:retsam >output 2>&1) &&
A dumb question. Why is this done in a sub-shell?
> +
> + grep "^ + [a-z0-9]\+\.\.\.[a-z0-9]\+[ ]*master -> master (forced update)$" output &&
> + grep "^ ! \[rejected\][ ]*master -> retsam (non-fast-forward)$" output &&
[a-z0-9] seems too broad to catch hexadecimal. "\+" to introduce ERE
elements to grep that expects BRE is a GNU extension, IIRC. You could use
egrep if you really want to say one-or-more, but I think in this case it
is better to simply replace it with a zero-or-more '*'. Why is a single
SP made into character class with "[ ]" pair?
> +
> + grep \
> +"To prevent you from losing history, non-fast-forward updates were rejected
> +Merge the remote changes before pushing again. See the '"'non-fast-forward'"'
> +section of '"'git push --help'"' for details." output
> +'
> +
> stop_httpd
> test_done
> --
> 1.6.6.rc1.249.g048b3
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-06 1:04 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20100105115620.GA27121@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> - Not using warning()
Ah, I forgot about locally fixing that one up. Sorry, and thanks.
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Junio C Hamano @ 2010-01-06 1:04 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Sebastian Thiel, Nanako Shiraishi, git
In-Reply-To: <be6fef0d1001031503h11cb65c6ha34eee345b9b7055@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> from your above message solely and setting aside your original patch,
> I presume that you want to introduce the ability to force progress
> reporting even if stderr isn't a terminal.
>
> I am working a feature (display progress for http operations) that
> happens to add this ability to git-push and git-fetch, by specifying
> the --progress option.
>
> Regarding git-pull - I guess it's only git-fetch (being
> transport-related) that reports progress?
Are you talking about this topic?
* tc/clone-v-progress (2009-12-26) 4 commits
- clone: use --progress to force progress reporting
- clone: set transport->verbose when -v/--verbose is used
- git-clone.txt: reword description of progress behaviour
- check stderr with isatty() instead of stdout when deciding to show progress
What do people think about it? I vaguely recall that somebody asked to
add a warning to release notes on the behaviour change to this series, and
I think it may be a worthwhile thing to do (e.g. "Earlier we did X but now
we do Y; change things in this way if you want us to keep doing X"), but
otherwise I think it is a sensible change.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Junio C Hamano @ 2010-01-06 1:02 UTC (permalink / raw)
To: Russell Steicke; +Cc: Dongas, git
In-Reply-To: <c1b8b6671001051607j6b6398d8gf08f7615a38de64e@mail.gmail.com>
Russell Steicke <russellsteicke@gmail.com> writes:
> Ah yes, I forgot about those files. I _think_ (but I'm not certain
> without digging into the code) that it's always safe to rm
> packed-refs, as that file is a cache for quicker access to the refs.
No what you think is incorrect, no it is not safe at all, and no it is not
a cache.
refs are created loose as files under $GIT_DIR/refs/. When pack-refs is
run (either from the toplevel or as part of gc), these loose ref files are
removed and instead written to $GIT_DIR/packed-refs file. When a new ref
is created or an existing ref is updated, only $GIT_DIR/refs/ is modified.
When reading or enumerating, a loose ref, if found, is used. Otherwise
a record in packed-refs is consulted. The consequences are:
- If you have $GIT_DIR/refs/heads/master and at the same time, an entry
for refs/heads/master exists in $GIT_DIR/packed-refs, removing the
entry in packed-refs happens to be safe, because it was already masked.
- If you do not have $GIT_DIR/refs/heads/old, but an entry for
refs/heads/old exists in $GIT_DIR/packed-refs, removing the entry in
packed-refs means you lose the "old" branch. You don't want to do
that.
- When deleting a ref, we remove it from $GIT_DIR/refs/, but at the same
time, if packed-refs contains an entry for it, we remove it from
there. Otherwise, the removal of the loose one will unmask the stale
entry in packed-refs file.
^ permalink raw reply
* Re: A question about changing remote repo name
From: Johannes Schindelin @ 2010-01-06 0:27 UTC (permalink / raw)
To: Russell Steicke; +Cc: Dongas, git
In-Reply-To: <c1b8b6671001051607j6b6398d8gf08f7615a38de64e@mail.gmail.com>
Hi,
On Wed, 6 Jan 2010, Russell Steicke wrote:
> On Tue, Jan 5, 2010 at 12:30 PM, Dongas <dongas86@gmail.com> wrote:
> > I did a few more steps:
> > root@ubuntu:/work/git-repo/free_monkey# grep -wrin 'origin' .
> > ./.git/packed-refs:2:abfae429bb4081043e84681e5ee94102085f87e0
> > refs/remotes/origin/master
> > ./.git/refs/remotes/karmic/HEAD:1:ref: refs/remotes/origin/master
> >
> > Change 'origin' to 'karmic' in above files.
>
> Ah yes, I forgot about those files. I _think_ (but I'm not certain
> without digging into the code) that it's always safe to rm
> packed-refs, as that file is a cache for quicker access to the refs.
For everybody reading this thread: DON'T!
Russel, it would be better if you knew about the mechanism before
making other people believe that it is safe to delete a file that is _not_
a cache, but _replaces_ the existing refs.
(Just mentioning that you only _think_ it is safe does not help; it is not
safe, but people will think that it is safe. Maybe you'll spend those 5
minutes in the future before sending a message like you did...)
Hth,
Dscho
^ permalink raw reply
* Re: A question about changing remote repo name
From: Russell Steicke @ 2010-01-06 0:07 UTC (permalink / raw)
To: Dongas; +Cc: git
In-Reply-To: <60ce8d251001042030l75c5443gf173f127ad206df3@mail.gmail.com>
On Tue, Jan 5, 2010 at 12:30 PM, Dongas <dongas86@gmail.com> wrote:
> I did a few more steps:
> root@ubuntu:/work/git-repo/free_monkey# grep -wrin 'origin' .
> ./.git/packed-refs:2:abfae429bb4081043e84681e5ee94102085f87e0
> refs/remotes/origin/master
> ./.git/refs/remotes/karmic/HEAD:1:ref: refs/remotes/origin/master
>
> Change 'origin' to 'karmic' in above files.
Ah yes, I forgot about those files. I _think_ (but I'm not certain
without digging into the code) that it's always safe to rm
packed-refs, as that file is a cache for quicker access to the refs.
At least it's never caused me any problems.
In any case, your approach of grepping the whole of .git for
interesting strings is a good way to learn about the implementation.
--
Virus found in this message.
^ permalink raw reply
* Re: Filename quoting / parsing problem
From: Andreas Gruenbacher @ 2010-01-06 0:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <201001022148.47841.agruen@suse.de>
On Saturday 02 January 2010 09:48:47 pm Andreas Gruenbacher wrote:
> On Saturday 02 January 2010 07:37:08 pm Junio C Hamano wrote:
> > I don't think it happened in the GNU land yet, and you would be the
> > person to know about it ;-).
>
> I'm working on it ...
The "experimental" branch [*] now has very lightly tested code for parsing
most extended headers ("index", "rename from", "rename to", "copy from", "copy
to", "old mode", "new mode", "deleted file mode", "new file mode"). Most
things should work, except:
* Doesn't parse filenames in "diff --git" lines. (I tried to argue why
those lines are a problem in this thread.)
* sha1 checksums are not verified right now. I'm not sure when that should
happen: always by default, or only optionally? (Like verifying file modes,
this is going to surprise a lot of users.)
* Similarity and dissimilarity headers are ignored.
* Binary diffs are no supported. I think GNU patch should recognize them and
give a reasonable message for now.
[*] http://git.savannah.gnu.org/cgit/patch.git/log/?h=experimental
Can you guys please do something to make parsing of filenames in "diff --git"
lines a lot easier, or unnecessary?
Thanks!
Andreas
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-05 23:13 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Heiko Voigt, Jens Lehmann, Git Mailing List, Junio C Hamano,
Shawn O. Pearce, Paul Mackerras, Lars Hjemli, Avery Pennarun
In-Reply-To: <20100106073718.6117@nanako3.lavabit.com>
Hi,
On Wed, 6 Jan 2010, Nanako Shiraishi wrote:
> I found this other discussion in the design area enlightening.
>
> http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621
Could you be so kind and summarize the result of the thread in something
like 2000 characters?
I am sorry, but what with the recent trend of a precious few Git mailing
list members using up my weekly Git time budget in less than half a day,
just by me reading their mails, it would be nice if at least _some_
discussions on the list could be concise and to the point.
Thanks,
Dscho
^ permalink raw reply
* cmake, was Re: submodules' shortcomings
From: Johannes Schindelin @ 2010-01-05 23:06 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Git Mailing List
In-Reply-To: <3af572ac1001051238t63e07a25hf9dd77056b79be89@mail.gmail.com>
Hi,
On Tue, 5 Jan 2010, Pau Garcia i Quiles wrote:
> For instance, I'd like to have a 'cmake' repository where I store all
> the FindBlah.cmake modules, so that I can share them from every
> repository, and not worry about users changing and committing in the
> main project instead of the submodule.
... which reminds me... it was you who wanted to provide a working recipe
to compile and install CMake on msysGit, right?
What happened in the meantime?
Ciao,
Dscho
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-05 23:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Git Mailing List, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli, Avery Pennarun
In-Reply-To: <7vd41oz9mp.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 5 Jan 2010, Junio C Hamano wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
> >> I think "clone" has a chicken-and-egg problem. If all of your
> >> project ... what kind of participant you are. It has to become
> >> two-step process; either "clone" going interactive in the middle, or
> >> you let the clone to happen and then "submodule init" to express that
> >> information.
> >
> > Yes, we can leave it that way for now (first "clone" and then
> > "submodule init <the submodules you need>"). We can migrate to the
> > "group mapping" functionality later (which would then allow to force
> > certain submodules to always be populated because they appear in every
> > group).
>
> Even with group mapping, you need to clone the superproject first, before
> seeing the mapping (which I would assume comes in the superproject).
That's just like saying "you only see the URL first, and you have to clone
before you see what the project is about".
So in effect you are saying that things are bad. But you do not take the
leap of imagination to say what we need to improve.
There are quite a number of settings which could benefit from git-clone --
finally -- learning to take more information than just the URL; autocrlf
and submodules' "grouping" (which is a lousy name, by the way) being the
most prominent examples (which the core Git developers very obviously do
not use, otherwise the state of things would not be as sorry as it is).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <1261172078-9174-1-git-send-email-bebarino@gmail.com>
Junio, could you tell us what happened to this thread?
After a lengthy discussion, nothing happened.
^ permalink raw reply
* Re: [RFC/PATCH] branch: new option --will-track
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dave Olszewski
In-Reply-To: <7vaaxhdu1f.fsf@alter.siamese.dyndns.org>
Junio, could you tell us what happened to this thread?
After "--will-track" was discussed and agreed not to be the best
solution, and "pull --remember" and "branch --configure" were
suggested, nothing happened.
^ permalink raw reply
* Re: [PATCH v2 2/3] format-patch: make full-diff enabled by default
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, Felipe Contreras, git
In-Reply-To: <1259408429-5685-3-git-send-email-felipe.contreras@gmail.com>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Nanako Shiraishi @ 2010-01-05 22:38 UTC (permalink / raw)
To: Adam Megacz; +Cc: git
In-Reply-To: <xuu2zl4tfuij.fsf@nowhere.com>
Quoting Adam Megacz <adam@megacz.com>
> Perhaps a preference (off by default) demanding that they be set
> explicitly when "git commit -m" is used?
Sverre pointed out why this won't work.
> Some people care more than others about the metadata; this is for the
> folks to whom it matters a lot.
So the only workable solution is to check your commits with "git show -s" until you become confident that you configured your new box correctly. Some people unfortunately don't care enough to do so, but it is for the people to whom it matters.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Nanako Shiraishi @ 2010-01-05 22:37 UTC (permalink / raw)
To: Heiko Voigt
Cc: Johannes Schindelin, Jens Lehmann, Git Mailing List,
Junio C Hamano, Shawn O. Pearce, Paul Mackerras, Lars Hjemli,
Avery Pennarun
In-Reply-To: <20100105142727.GA83546@book.hvoigt.net>
Quoting Heiko Voigt <hvoigt@hvoigt.net>
> On Tue, Jan 05, 2010 at 10:46:11AM +0100, Johannes Schindelin wrote:
>> On Tue, 5 Jan 2010, Jens Lehmann wrote:
>> > Yes. This synchronization could be either obsoleted by only using
>> > .gitmodules or automated.
>>
>> I start to wonder whether the insistence that .gitmodules' settings must
>> be overrideable makes any sense in practice.
>
> I just read this and felt the need to comment.
>
> Yes, it definitely makes sense in practise to have it overrideable
> otherwise we loose the distributed nature of git for submodules.
>
> Imagine you fork a project and you want to work with others on a change
> that involves chaning a subproject. If you can not override .gitmodules
> you can only work on the central repository.
>
> I am actually working like this in practise. I have a private clone of
> all the subprojects msysgit has and commit/push locally first. Once I
> sense the change is going to be useful for a wider audience I send it
> upstream. This would be more uncomfortable if it is not overideable.
>
> But I know what you mean by the general confusion about manual updates.
> So how about an approach like this:
>
> * clone will initialise all submodules in .git/config from .gitmodules
>
> * if a change in .gitmodules happens git scans .git/config for that
> entry and in case nothing is there it syncronises the new one and
> notifies the user.
>
> * if a change in .gitmodules happens and the entry before was the same
> in .git/config we also automatically update that entry there.
>
> * In every other case we just leave .git/config alone.
>
> Did I miss anything? I think you should get the idea and that it could
> get rid of the confusion caused by manual .gitmodule updates.
>
> cheers Heiko
>
> P.S.: Additionally (for my use case) we could add a "hint mechanism"
> which allows git to "guess" a new submodules address. For example in
> case I have all my local clones on "git@my.server.net:<modulename>.git".
> Now when a new submodule gets seen in .gitmodules it will infer the
> address from the hint configuration and not take the original one from
> upstream.
Thanks for sharing your thoughts. I find this discussion very interesting.
I found this other discussion in the design area enlightening.
http://thread.gmane.org/gmane.comp.version-control.git/47466/focus=47621
It was before I started using git heavily and I don't see many people who were in the discussion yet in the current thread, but I think it is worth reading.
P.S. A happy new year to everybody!
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: git-cherry-pick problem - directory not touched by commit is marked "added by us"
From: Sam Vilain @ 2010-01-05 21:37 UTC (permalink / raw)
To: Hakim Cassimally; +Cc: git
In-Reply-To: <82cfa8031001050433r6d705222qf905c929ad6395c4@mail.gmail.com>
On Tue, 2010-01-05 at 12:33 +0000, Hakim Cassimally wrote:
> I got into a bit of trouble with a git-cherry-pick last night, and
> though mugwump
> and others on #git helped me as far as a workaround, I'm still very confused,
> and would like to make sure it doesn't happen again
Yes, that was me. I'm very confused by the bug, too.
[...]
> WHAT HAPPENS
> ============
>
> When I'm in (stable), and try to cherry-pick the change from (experimental),
> git thinks that I'm making a massive number of changes in a directory that
> wasn't touched by the relevant commit.
[...]
> (stable) $ git --version
> git version 1.6.6
> # I tried previously on 1.6.0.4 but upgraded in case it helped
>
> (stable) $ git status
> # On branch stable
> # nothing to commit (working directory clean)
>
> (stable) $ git show --stat 301afce1
> commit 301afce1c78380276d208077ef4ec76b469c1024
> Author: osfameron <...>
> Date: Wed Dec 23 23:45:20 2009 +0000
>
> Proof of concept for import module (parse Excel)
>
> bin/upload_module.pl | 142
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 142 insertions(+), 0 deletions(-)
>
> (stable) $ git whatchanged -1 301afce1
> commit 301afce1c78380276d208077ef4ec76b469c1024
> Author: osfameron <...>
> Date: Wed Dec 23 23:45:20 2009 +0000
>
> Proof of concept for import module (parse Excel)
>
> :000000 100644 0000000... c90e261... A bin/upload_module.pl
So by here, we know that the commit only affects that single file. No
funny stuff like mode changes of other files.
> (stable) $ git cherry-pick 301afce1
> Finished one cherry-pick.
> www/client/css/admin-clean.css: needs merge
> www/client/css/admin.css: needs merge
> www/client/css/error.css: needs merge
> www/client/css/public.css: needs merge
> www/client/css/user-clean.css: needs merge
> <...snip>
> www/client/css/admin-clean.css: unmerged
> (832c41e99d19f2dd39c9cf3709f14619ffab24b8)
> www/client/css/admin.css: unmerged
> (8e7cd850bf40d1a921b1f62ce0945abd374fa55d)
> www/client/css/error.css: unmerged
> (88945d05640c0820c9cf68922392573d4ac07b2c)
> <...snip>
> ...
> error: Error building trees
Then, wham, these files want to be changed. What is the diff-tree
inside revert/cherry-pick doing differently to the one in log?
> (stable) $ git status
> # On branch stable
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: bin/upload_module.pl
> #
> # Unmerged paths:
> # (use "git reset HEAD <file>..." to unstage)
> # (use "git add <file>..." to mark resolution)
> #
> # added by us: www/client/css/admin-clean.css
> # added by us: www/client/css/admin.css
> # added by us: www/client/css/error.css
> # added by us: www/client/css/public.css
> <...snip>
Hakim, one more useful thing in this situation would be to show the
state of these files in the index;
git ls-files -s -u
Also take the 'git ls-tree -r HEAD', 'git ls-tree -r 301afce1' and 'git
ls-tree -r 301afce1^' output, and grep for the files in question. The
answer (or at least a bug triage) should be in the output of those
commands.
You can reproduce exactly the merge by making a new branch at the
position where you were attempting to land the cherry pick before, and
checking that branch out.
One last test, would be to check that it happens on a clean clone of the
repository. I don't think that you're hitting any repository-local
behaviour (eg, the ability to mark certain files as "always ignore") but
you never know. These commands are all being run on the same working
copy, right?
Thanks for your persistence,
Sam
^ permalink raw reply
* Re: [PATCH 9/9] rerere forget path: forget recorded resolution
From: Johannes Sixt @ 2010-01-05 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1262122958-9378-10-git-send-email-gitster@pobox.com>
Junio C Hamano schrieb:
> After you find out an earlier resolution you told rerere to use was a
> mismerge, there is no easy way to clear it. A new subcommand "forget" can
> be used to tell git to forget a recorded resolution, so that you can redo
> the merge from scratch.
> ...
> diff --git a/rerere.c b/rerere.c
> index f013ae7..c1da6f6 100644
> --- a/rerere.c
> +++ b/rerere.c
> ...
> +static int handle_cache(const char *path, unsigned char *sha1)
> +{
> +...
> + ll_merge(&result, path, &mmfile[0],
> + &mmfile[1], "ours",
> + &mmfile[2], "theirs", 0);
When you simply call ll_merge(), will it obey any merge drivers that are
defined in .gitattributes? Do we care about them?
I already had an implementation of "rerere forget" before you presented
this solution, but it relies on that the user calls "checkout
--conflict=merge" first. One reason (besides its simplicity) was that it
does not have to care how the merge is computed.
[I haven't submitted my solution, yet, because I haven't had the time to
do this large merge where I expect to make use "rerere forget", testing
its usefulness.]
-- Hannes
^ permalink raw reply
* Re: A question about changing remote repo name
From: David Aguilar @ 2010-01-05 21:15 UTC (permalink / raw)
To: Dongas; +Cc: Russell Steicke, git
In-Reply-To: <60ce8d251001042030l75c5443gf173f127ad206df3@mail.gmail.com>
Hi,
On Tue, Jan 05, 2010 at 12:30:03PM +0800, Dongas wrote:
> 2010/1/5 Russell Steicke <russellsteicke@gmail.com>:
> > On Mon, Jan 4, 2010 at 2:45 PM, Dongas <dongas86@gmail.com> wrote:
>
> Thanks a lot, Russell.
> I followed you instruction but it seemed it needs more changes.
>
> Execute your steps....
> Becomes:
> root@ubuntu:/work/git-repo/free_monkey# tree -a
Just a note: I would recommend against being root.
You cloned the repo so you should own it.
More below...
> root@ubuntu:/work/git-repo/free_monkey# cat .git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "karmic"]
> url = git@192.168.1.116:free_monkey.git
> fetch = +refs/heads/*:refs/remotes/karmic/*
> [branch "master"]
> remote = karmic
> merge = refs/heads/master
>
> But the result was:
> root@ubuntu:/work/git-repo/free_monkey# git branch -a
> * master
> karmic/HEAD
> origin/master
> The 'origin/master' was still not changed.
A safter alternative would be to leave the "origin" lines in
place as a duplicate of karmic:
[remote "karmic"]
url = git@192.168.1.116:free_monkey.git
fetch = +refs/heads/*:refs/karmic/origin/*
[remote "origin"]
url = git@192.168.1.116:free_monkey.git
fetch = +refs/heads/*:refs/remotes/origin/*
At that point you will have two remotes, "karmic" and "origin".
"git fetch karmic" to get the latest branches.
Finally, "git remote rm origin" to remove all references to it.
> I did a few more steps:
> root@ubuntu:/work/git-repo/free_monkey# grep -wrin 'origin' .
> ./.git/packed-refs:2:abfae429bb4081043e84681e5ee94102085f87e0
> refs/remotes/origin/master
> ./.git/refs/remotes/karmic/HEAD:1:ref: refs/remotes/origin/master
>
> Change 'origin' to 'karmic' in above files.
You can skip this step by using "git remote rm" as described
above.
> The steps are a little complicated.
> Do you know if there's a way to rename the remote on server side?
> If there is, then everyone could just clone the project with a new
> remote name rather than the defaul 'origin'.
Unfortunately, no. "origin" is actually a local thing.
Your local git client gives it that name. As you can see, the
remote does not care whether we call it "origin" or "karmic".
There were some patches flying around on the ML some time ago
that allowed you to change the default "origin" name on the
client side at "git clone" time (or maybe patches never
materialized and it was purely discussion).
That was a while ago (probably over a year ago) and this wasn't
anybody's itch to scratch in the meantime so nothing every
materialized. It think this is only the 2nd time this has come
up in that whole time. Sorry, I wasn't able to find the thread.
Here's a nice middle ground --
instead of naming your branch "master" you can call your default
branch "karmic".
To make it the default for "git clone" then you'll need to push
your local master branch and call it "karmic" over there:
git push origin master:karmic
Then, go to that server and change the repo's HEAD entry so that
it points to karmic instead of master.
ssh admin@gitbox
cd /path/to/repo.git
vi HEAD
>From then on, everyone who clones the repo will have a "karmic"
branch by default instead of the master branch.
To get that branch on repos that were cloned before the change:
git fetch origin
git checkout -b karmic origin/karmic
With this setup you might even want to remove the "master"
branch altogether since it might be confusing to have both:
Once:
git push origin :master
In everyone's repo:
git remote prune origin
You will need to make sure everyone has either:
a) cloned from the new master-less repo
b) run the "checkout -b" and "remote prune" commands
Otherwise someone'll likely "git push" the master branch back
into existence.
--
David
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Johannes Sixt @ 2010-01-05 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbr1bagk.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> While you are technically correct that the change you made in t4030 is not
> justified by the commit log message in the sense that the "hexdump" script
> will go through run_command() interface and is not subject to the special
> rules filter writers need to keep in mind, the patch text itself is a good
> change, isn't it?
The patch text is good, but since it will not make a difference (and there
are a ton of other places that use /bin/sh successfully), the change is
not warrented at this time, IMO.
> As "run-command: convert simple callsites to use_shell" is the one that
> changes the filter_buffer(), do you want to have t0021 patch before that
> one, to prepare the test for the coming change?
Well, the test will break on Windows only after "run-command: optimize out
useless shell calls", and I wrote the commit message accordingly. If you
move it before that one (and if you are picky) the commit message should
be changed as well.
-- Hannes
^ permalink raw reply
* Re: submodules' shortcomings, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Pau Garcia i Quiles @ 2010-01-05 20:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001042217370.4985@pacific.mpi-cbg.de>
Hello,
Let me pop here to support Johannes: I agree with every single point
he enumerated. Every. Single. Point.
For instance, I'd like to have a 'cmake' repository where I store all
the FindBlah.cmake modules, so that I can share them from every
repository, and not worry about users changing and committing in the
main project instead of the submodule. I can't. Subversion externals
still rule in that regard.
On Mon, Jan 4, 2010 at 11:29 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 4 Jan 2010, Jens Lehmann wrote:
>
>> Am 04.01.2010 10:44, schrieb Johannes Schindelin:
>> > The real problem is that submodules in the current form are not very
>> > well designed.
>>
>> IMVHO using the tree sha1 for a submodule seems to be the 'natural' way
>> to include another git repo. And it gives the reproducibility i expect
>> from a scm. Or am i missing something?
>
> You do remember the discussion at the Alles wird Git about the need for
> Subversion external-like behavior, right?
>
>> It looks to me as most shortcomings come from the fact that most git
>> commands tend to ignore submodules (and if they don't, like git gui and
>> gitk do now, they e.g. only show certain aspects of their state).
>
> It is not only ignoring. It is not being able to cope with the state only
> submodules can be in (see below).
>
>> Submodules are in heavy use in our company since last year. Virtually
>> every patch i submitted for submodules came from that experience and
>> scratched an itch i or one of my colleagues had (and the situation did
>> already improve noticeably by the few things we changed). We are still
>> convinced that using submodules was the right decision. But some work
>> has still to be done to be able to use them easily and to get rid of
>> some pitfalls.
>
> Submodules may be the best way you have in Git for your workflow ATM.
> But that does not mean that the submodule design is in any way
> thought-through.
>
> Just a few shortcomings that do show up in my main project (and to a
> small extent in msysGit, as you are probably aware):
>
> - submodules were designed with a strong emphasis on not being forced to
> check them out. But Git makes it very unconvenient to actually check
> submodules out, let alone check them out at clone-time. And it is
> outright impossible to _enforce_ a submodule to be checked out.
>
> - among other use cases, submodules are recommended for sharing content
> between two different repositories. But it is part of the design that it
> is _very_ easy to forget to commit, or push the changes in the submodule
> that are required for the integrity of the superproject.
>
> - that use case -- sharing content between different repositories -- is
> not really supported by submodules, but rather an afterthought. This is
> all too obvious when you look at the restriction that the shared content
> must be in a single subdirectory.
>
> - submodules would be a perfect way to provide a fast-forward-only media
> subdirectory that is written to by different people (artists) than to
> the superproject (developers). But there is no mechanism to enforce
> shallow fetches, which means that this use case cannot be handled
> efficiently using Git.
>
> - related are the use cases where it is desired not to have a fixed
> submodule tip committed to the superproject, but always to update to the
> current, say, master (like Subversion's externals). This use case has
> been wished away by the people who implemented submodules in Git. But
> reality has this nasty habit of ignoring your wishes, does it not?
>
> - there have been patches supporting rebasing submodules, i.e.
> submodules where a "git submodule update" rebases the current branch to
> the revision committed to the superproject rather than detaching the
> HEAD, which everybody who ever contributed to a project with submodules
> should agree is a useful thing. But the patches only have been discussed
> to death, to the point where the discussion's information content was
> converging to zero, yet the patches did not make it into Git. (FWIW
> this is one reason why I refuse to write patches to git-submodule.sh: I
> refuse to let my time to be wasted like that.)
>
> - working directories with GIT_DIRs are a very different beast from single
> files. That alone leads to a _lot_ of problems. The original design of
> Git had only a couple of states for named content (AKA files): clean,
> added, removed, modified. The states that are possible with submodules
> are for the most part not handled _at all_ by most Git commands (and it
> is sometimes very hard to decide what would be the best way to handle
> those states, either). Just think of a submodule at a different
> revision than committed in the superproject, with uncommitted changes,
> ignored and unignored files, a few custom hooks, a bit of additional
> metadata in the .git/config, and just for fun, a few temporary files in
> .git/ which are used by the hooks.
>
> - while it might be called clever that the submodules' metadata are stored
> in .gitmodules in the superproject (and are therefore naturally tracked
> with Git), the synchronization with .git/config is performed exactly
> once -- when you initialize the submodule. You are likely to miss out
> on _every_ change you pulled into the superproject.
>
> All in all, submodules are very clumsy to work with, and you are literally
> forced to provide scripts in the superproject to actually work with the
> submodules.
>
>> > In ths short run, we can paper over the shortcomings of the submodules
>> > by introducing a command line option "--include-submodules" to
>> > update-refresh, diff-files and diff-index, though.
>>
>> Maybe this is the way to go for now (and hopefully we can turn this
>> option on by default later because we did the right thing ;-).
>
> I do not think that --include-submodules is a good default. It is just
> too expensive in terms of I/O even to check the status in a superproject
> with a lot of submodules.
>
> Besides, as long as there is enough reason to have out-of-Git alternative
> solutions such as repo, submodules deserve to be 2nd-class citizens.
>
> Ciao,
> Dscho
>
> --
> 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
>
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: David Aguilar @ 2010-01-05 20:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Adam Megacz, git
In-Reply-To: <fabb9a1e1001041452q299f1f28hff041eb06fd24b1f@mail.gmail.com>
On Mon, Jan 04, 2010 at 05:52:42PM -0500, Sverre Rabbelier wrote:
> Heya,
>
> On Mon, Jan 4, 2010 at 16:08, Adam Megacz <adam@megacz.com> wrote:
> > Perhaps a preference (off by default) demanding that they be set
> > explicitly when "git commit -m" is used?
>
> Heh, what use would that be? On a different/new box you would have
> neither that setting nor the email set, so that doens't solve the
> problem methinks :P.
>
> --
> Cheers,
>
> Sverre Rabbelier
Workaround:
If you use "git commit -s" it includes a Signed-off-by line
which includes your name and email.
Seeing "Signed-off-by: root <root@localhost>" would give you a
hint that you should abort the commit, set the vars, and
try again.
--
David
^ permalink raw reply
* Re: git file sharing/versioning.
From: Nicolas Sebrecht @ 2010-01-05 20:10 UTC (permalink / raw)
To: Bas Driessen; +Cc: git, Nicolas Sebrecht
In-Reply-To: <1262580426.9041.21.camel@ams.xobas.net>
The 04/01/10, Bas Driessen wrote:
> I have a project where I have 2 trees with several hundreds of files.
> Let's call them tree1 and tree2. Only a handful of files in tree2 are
> different. What is the best way to set this up in GIT? Basically most
> files in tree2 should act as a symbolic link to tree1. So if the file
> changes in tree 1, it automatically changes in tree 2. Obviously, I
> don't want to store everything double. Branching does not appear to be
> an option as changes in tree1 would not be visible in the tree2 branch.
Look at:
git merge --help
git rebase --help
git cherry-pick --help
--
Nicolas Sebrecht
^ 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