* Re: reflog weirdness
From: Junio C Hamano @ 2007-12-29 0:06 UTC (permalink / raw)
To: Thien-Thi Nguyen; +Cc: git
In-Reply-To: <87fxxme8x9.fsf@ambire.localdomain>
Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> () Junio C Hamano <gitster@pobox.com>
> () Fri, 28 Dec 2007 14:01:55 -0800
>
> Was it a buggy "git commit" command, or a bad commit log
> message was fed to "git commit" by the user, and there is
> nothing for me to worry about?
>
> i'm sorry, even though it was only a couple days ago, the actual
> events are far back in my memory, so i can't say. i wouldn't
> worry about it -- probably user error. (i'm new w/ git. most of
> the time i drive it from w/in emacs, which is well behaved; it is
> when i leave that comparative safety to do some flailing from the
> command-line that things go weird.)
>
> i suppose one way to improve git would be to test how it handles
> interruption (control-c in the middle of a commit, for example).
> a bit tricky to arrange (reproducibly), though...
>
> now i go search the docs for how to replace that log message.
"git-rebase -i"
^ permalink raw reply
* [ANNOUNCE] ugit: the pythonic git gui
From: David @ 2007-12-28 22:49 UTC (permalink / raw)
To: git
ugit, the pyqt-based git gui, has been taking shape as of late.
First off, I'd like to thank everyone that replied with suggestions
and criticism. This list is extremely helpful with regards to
providing honest software critiques.
New features since the last announcement (almost all of which were
mentioned in one way or another on this list):
* inotify support (we've removed the "Rescan" button)
* Patch hunk un/staging
* Allows un/staging selected patch hunk lines (without --unidiff-zero)
* Prepped for i18n ("env LANG=ja_JP ugit" looks pretty cool now)
* I'm a westerner, so the unstaged list is now on the left and the
staged list is on the right (thanks Jason)
* Optimizations to improve the interactivity of the patch browser
* Misc. fixes for MacOS and Windows (thanks Steffan and Sebastian)
* Uses default system colors whenever possible [no more darkness] (thanks Alex)
* No longer requires PYTHONPATH
Source code (requires pyqt4-dev-tools to build):
http://repo.or.cz/w/ugit.git
Tarballs (require a stock pyqt-4.3 installation):
http://ugit.justroots.com/
I'll try and get some .deb, .rpm, etc. action happening soon.
p.s.
If you read ugit as "(f)uh-git" or "ugly-git", then that's good since
I think that falls in line with the git style ;-)
^ permalink raw reply
* Re: reflog weirdness
From: Thien-Thi Nguyen @ 2007-12-28 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzm2cwbw.fsf@gitster.siamese.dyndns.org>
() Junio C Hamano <gitster@pobox.com>
() Fri, 28 Dec 2007 14:01:55 -0800
Was it a buggy "git commit" command, or a bad commit log
message was fed to "git commit" by the user, and there is
nothing for me to worry about?
i'm sorry, even though it was only a couple days ago, the actual
events are far back in my memory, so i can't say. i wouldn't
worry about it -- probably user error. (i'm new w/ git. most of
the time i drive it from w/in emacs, which is well behaved; it is
when i leave that comparative safety to do some flailing from the
command-line that things go weird.)
i suppose one way to improve git would be to test how it handles
interruption (control-c in the middle of a commit, for example).
a bit tricky to arrange (reproducibly), though...
now i go search the docs for how to replace that log message.
thi
^ permalink raw reply
* [PATCH] git-sh-setup: document git_editor() and get_author_ident_from_commit()
From: Miklos Vajna @ 2007-12-28 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
These 2 functions were missing from the manpage.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-sh-setup.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-sh-setup.txt b/Documentation/git-sh-setup.txt
index 1ea1faa..fd024d7 100644
--- a/Documentation/git-sh-setup.txt
+++ b/Documentation/git-sh-setup.txt
@@ -44,6 +44,10 @@ set_reflog_action::
end-user action in the reflog, when the script updates a
ref.
+git_editor::
+ runs the proper editor based on GIT_EDITOR, core.editor, VISUAL or
+ EDITOR.
+
is_bare_repository::
outputs `true` or `false` to the standard output stream
to indicate if the repository is a bare repository
@@ -57,6 +61,10 @@ require_work_tree::
if so. Used by scripts that require working tree
(e.g. `checkout`).
+get_author_ident_from_commit::
+ outputs code for use with eval to set the GIT_AUTHOR_NAME,
+ GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
+
Author
------
--
1.5.4.rc2-dirty
^ permalink raw reply related
* Re: reflog weirdness
From: Junio C Hamano @ 2007-12-28 22:01 UTC (permalink / raw)
To: Thien-Thi Nguyen; +Cc: git
In-Reply-To: <87prwqec4a.fsf@ambire.localdomain>
Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> i see that the body of the log message (three bytes)
> corresponds to the first three bytes of the associated
> line in .git/logs/HEAD.
Thanks.
Was it a buggy "git commit" command, or a bad commit log message
was fed to "git commit" by the user, and there is nothing for me
to worry about?
^ permalink raw reply
* Re: [PATCH] git-pull: warn if only fetching tags with the -t switch
From: Junio C Hamano @ 2007-12-28 21:58 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Gerrit Pape, git, Shawn Pearce
In-Reply-To: <alpine.LNX.1.00.0712281141450.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On the other hand, the command that's difficult with (1) is "get all of
> the latest tags, but not even the default other refs", and I don't think
> that's something that people actually want to do in general, so it should
> be fine to go with (1).
I agree. "Behave as if no --tags was given (so an explicit
refspec on the command line overrides configured ones, or no
explicit refspecs on the command line takes configured ones),
but do not auto-follow tags and fetch all tags as not-for-merge
entries" would be the most sensible semantics for the option, as
you say.
>> This is a bit more involved change than I would want to have
>> during -rc freeze.
>
> Certainly. I think, though, that the OP's patch, plus a check that --tags
> was given on the command line in the first place, would be worthwhile.
Sounds sensible.
---
git-pull.sh | 66 +++++++++++++++++++++++++++++++++++-----------------------
1 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 698e82b..fa97b0f 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -72,6 +72,40 @@ do
shift
done
+error_on_no_merge_candidates () {
+ exec >&2
+ for opt
+ do
+ case "$opt" in
+ -t|--t|--ta|--tag|--tags)
+ echo "Fetching tags only, you probably meant:"
+ echo " git fetch --tags"
+ exit 1
+ esac
+ done
+
+ curr_branch=${curr_branch#refs/heads/}
+
+ echo "You asked me to pull without telling me which branch you"
+ echo "want to merge with, and 'branch.${curr_branch}.merge' in"
+ echo "your configuration file does not tell me either. Please"
+ echo "name which branch you want to merge on the command line and"
+ echo "try again (e.g. 'git pull <repository> <refspec>')."
+ echo "See git-pull(1) for details on the refspec."
+ echo
+ echo "If you often merge with the same branch, you may want to"
+ echo "configure the following variables in your configuration"
+ echo "file:"
+ echo
+ echo " branch.${curr_branch}.remote = <nickname>"
+ echo " branch.${curr_branch}.merge = <remote-ref>"
+ echo " remote.<nickname>.url = <url>"
+ echo " remote.<nickname>.fetch = <refspec>"
+ echo
+ echo "See git-config(1) for details."
+ exit 1
+}
+
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
git-fetch --update-head-ok "$@" || exit 1
@@ -105,33 +139,13 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
case $? in
- 0) ;;
- 1) echo >&2 "You are not currently on a branch; you must explicitly"
- echo >&2 "specify which branch you wish to merge:"
- echo >&2 " git pull <remote> <branch>"
- exit 1;;
- *) exit $?;;
+ 0) error_on_no_merge_candidates "$@";;
+ 1) echo >&2 "You are not currently on a branch; you must explicitly"
+ echo >&2 "specify which branch you wish to merge:"
+ echo >&2 " git pull <remote> <branch>"
+ exit 1;;
+ *) exit $?;;
esac
- curr_branch=${curr_branch#refs/heads/}
-
- echo >&2 "You asked me to pull without telling me which branch you"
- echo >&2 "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo >&2 "your configuration file does not tell me either. Please"
- echo >&2 "name which branch you want to merge on the command line and"
- echo >&2 "try again (e.g. 'git pull <repository> <refspec>')."
- echo >&2 "See git-pull(1) for details on the refspec."
- echo >&2
- echo >&2 "If you often merge with the same branch, you may want to"
- echo >&2 "configure the following variables in your configuration"
- echo >&2 "file:"
- echo >&2
- echo >&2 " branch.${curr_branch}.remote = <nickname>"
- echo >&2 " branch.${curr_branch}.merge = <remote-ref>"
- echo >&2 " remote.<nickname>.url = <url>"
- echo >&2 " remote.<nickname>.fetch = <refspec>"
- echo >&2
- echo >&2 "See git-config(1) for details."
- exit 1
;;
?*' '?*)
if test -z "$orig_head"
^ permalink raw reply related
* Re: reflog weirdness
From: Thien-Thi Nguyen @ 2007-12-28 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhci2ectr.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
() Junio C Hamano <gitster@pobox.com>
() Fri, 28 Dec 2007 13:20:16 -0800
$ vi .git/logs/HEAD
and truncate that line after "commit: " to remove the
part that would normally show the one-line commit log
message.
thanks for the tip. i'll do that as soon as i've had a
chance to ponder the repercussions. in the meantime...
How does commit 20d9d23 look like (the tracked contents
are not interesting --- the commit log message is)?
here is the (again, not inlined due to strange bytes) top of
"git show 20d9d23" output:
[-- Attachment #2: top of \"git show\" output --]
[-- Type: application/octet-stream, Size: 257 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
i see that the body of the log message (three bytes)
corresponds to the first three bytes of the associated
line in .git/logs/HEAD.
thi
^ permalink raw reply
* Re: reflog weirdness
From: Junio C Hamano @ 2007-12-28 21:20 UTC (permalink / raw)
To: Thien-Thi Nguyen; +Cc: git
In-Reply-To: <87ve6iegny.fsf@ambire.localdomain>
Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> i'd like to get rid of (or somehow get git to hide) the {21} line.
> any hints?
$ vi .git/logs/HEAD
and truncate that line after "commit: " to remove the part that
would normally show the one-line commit log message.
It would be more interesting to know why garbage follows
"commit: " on that one entry, though. How does commit 20d9d23
look like (the tracked contents are not interesting --- the
commit log message is)?
^ permalink raw reply
* reflog weirdness
From: Thien-Thi Nguyen @ 2007-12-28 19:57 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
hello,
i use git-1.5.3.5 and see the following fragment from "git reflog"
(not inline due to binary values):
[-- Attachment #2: fragment of \"git reflog\" output --]
[-- Type: application/octet-stream, Size: 384 bytes --]
[-- Attachment #3: Type: text/plain, Size: 84 bytes --]
i'd like to get rid of (or somehow get git to hide) the {21} line.
any hints?
thi
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: Björn Steinbrink @ 2007-12-28 18:54 UTC (permalink / raw)
To: adr3nald0s; +Cc: Daniel Barkalow, git
In-Reply-To: <m3fxxm7jp6.fsf@euroclydon.lan>
On 2007.12.28 12:33:41 -0600, adr3nald0s@gmail.com wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:
> >
> >> When you say it linearizes history how is this done.
> >
> > Rebase takes a list of commits that are in the current branch and
> > aren't in the origin branch as what it's going to work on; these are
> > ordered in some arbitrary way such that children always follow parents. It
> > then resets to the origin branch's commit, and, in sequence, cherry-picks
> > each of the commits in the working list.
>
> Thanks again for the clear explanation.
>
> > In theory, of course, it could try to resolve conflicts by looking through
> > the rest of the list for merges which would have those conflicts and using
> > what that merge did.
>
> Given the implementation, this would be just plain ugly. I would not
> want to attempt to implement something like this, nor would I expect
> anyone else to do so.
I wouldn't make sense either. The conflict resolution that was done in
the merge commit might need stuff from commits that haven't been rebased
yet. For example a new function that was introduced later, it was
available for the merge, but is still missing from the rebased linear
history.
That said, what _might_ make sense is to teach interactive rebase with
-p to use "cherry-pick -m1" or whatever instead of "merge" to recreate
the merge commits (or maybe it does that already now? didn't check...).
That way, it wouldn't have to rely on rerere being enabled to avoid the
repeated resolving of the merge conflicts. I'm not sure how that would
need to interact with new changes introduces into one of the rewritten
branches.
Björn
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: adr3nald0s @ 2007-12-28 18:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: adr3nald0s, git
In-Reply-To: <alpine.LNX.1.00.0712281246330.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:
>
>> When you say it linearizes history how is this done.
>
> Rebase takes a list of commits that are in the current branch and
> aren't in the origin branch as what it's going to work on; these are
> ordered in some arbitrary way such that children always follow parents. It
> then resets to the origin branch's commit, and, in sequence, cherry-picks
> each of the commits in the working list.
Thanks again for the clear explanation.
> In theory, of course, it could try to resolve conflicts by looking through
> the rest of the list for merges which would have those conflicts and using
> what that merge did.
Given the implementation, this would be just plain ugly. I would not
want to attempt to implement something like this, nor would I expect
anyone else to do so.
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: Daniel Barkalow @ 2007-12-28 17:58 UTC (permalink / raw)
To: adr3nald0s; +Cc: git
In-Reply-To: <m3k5my7r1u.fsf@euroclydon.lan>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2163 bytes --]
On Fri, 28 Dec 2007, adr3nald0s@gmail.com wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This will rebase temp0 (= v2.6.16) onto topic/test. This process
> > linearizes the history being rebased, and conflicts in that history (that
> > were resolved in the merges) show up when the second change to those lines
> > gets introduced.
>
> Thank you for the explaination of why this is happening. This is
> something I had not considered WRT git-rebase.
>
> When you say it linearizes history how is this done. Mentally I still
> have a model of where the "mainline" is at all times and I assumed
> that git-rebase was following this mainline. However, upon
> reflection, I realize this is naïve.
>
> When there is a branch and a subsequent merge, does rebase follow both
> branches? If so, why does it not use the original merged result for
> the newly rebased file if there are no conflicts between the original
> merge result and the file that is being rebased onto as compared to
> their mutual ancestor?
Rebase takes a list of commits that are in the current branch and
aren't in the origin branch as what it's going to work on; these are
ordered in some arbitrary way such that children always follow parents. It
then resets to the origin branch's commit, and, in sequence, cherry-picks
each of the commits in the working list. This has two implications:
- the result is always linear, even if there are forks and merges in the
old history, because the new history is formed out of a single sequence
of cherry-picks, ignoring the shape of the original.
- merge results from the old history aren't available, because they're in
a commit later in the list than the commit where the cherry-picking
finds a conflict.
In theory, of course, it could try to resolve conflicts by looking through
the rest of the list for merges which would have those conflicts and using
what that merge did. But that's not at all easy, due to the structure of
the process, and it's rare that people actually want to rebase history
with forks in it, anyway, so it hasn't been done.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-pull: warn if only fetching tags with the -t switch
From: Daniel Barkalow @ 2007-12-28 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Shawn Pearce
In-Reply-To: <7vve6je349.fsf@gitster.siamese.dyndns.org>
On Thu, 27 Dec 2007, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
>
> > Subject: [PATCH] git-pull: warn if only fetching tags with the -t switch
> >
> > git-pull -t|--tags isn't supposed to be run, remove that option from
> > fetch-options.txt, and explicitely add it to git-fetch.txt. Have git pull
> > still fetch tags with the -t switch, but warn afterwards to better use
> > git fetch --tags, and error out.
> > ---
> >
> > How about this?
>
> Thanks.
>
> We coulc go with this for the time being for 1.5.4, but I am not
> absolutely confident that ...
>
> > + # warn if only tags have been fetched
> > + not_for_merge=$(sed -e '/ not-for-merge tag/d' \
> > + "$GIT_DIR"/FETCH_HEAD)
> > + if test "$not_for_merge" = ''; then
>
> ... FETCH_HEAD having nothing but not-for-merge tags would
> happen _only_ when "pull --tags" is done. If there are (bogus)
> command line other than "pull --tags" that results in this
> situation, we would be issuing a wrong error message.
>
> A trivial example. If you misconfigure your .git/config like
> this:
>
> [remote "origin"]
> url = ...
> fetch = refs/head/*:refs/remotes/origin/*
>
> and say:
>
> git pull
>
> without even "--tags", then the resulting .git/FETCH_HEAD would
> be empty, and the above test will trigger, even though the
> correct diagnosis is the error message we currently give the
> user.
Doesn't git-fetch return an error if the only pattern doesn't match
anything? I think it's a bug in git-fetch if it returns with no helpful
message and no error status, and a bug in git-pull if the fetch's
complaint doesn't override any messages git-pull might give afterward.
After all, the user will still have an unsolved problem if "git fetch"
above were to succeed silently.
So the only interesting case for git-pull is when MERGE_HEAD is not empty
after the fetch, but doesn't contain anything marked for merging.
This means that either (1) the default things-to-merge doesn't include
anything in the default things-to-fetch, and neither was replaced; or (2)
the default things-to-merge doesn't include anything in the specified
things-to-fetch, and the things-to-merge wasn't replaced; or (3) the
specified things-to-merge doesn't include anything in the specified
things-to-fetch.
(3) is impossible, since you can only specify things-to-merge as what
you're specifying for things-to-fetch, and the latter is non-empty.
(2) is only possible with --tags, which is (currently) the only thing that
can remove items from things-to-fetch without replacing things-to-merge as
well. This is where we want the special error message.
(1) is what we give the usual error message for.
So the sole case I can see where this patch gives the wrong message is
when the default things-to-fetch, so far as it matches anything,
matches only tags, and these are not for merging. That is, if you are, in
fact, fetching tags only, but by virtue of a configuration file that
fetches tags and doesn't (successfully) fetch anything else.
I'd say, just add a check that --tags was given on the git-pull command
line to this test.
> Come to think of it, "git pull <anything>" is "git fetch
> <anything>" followed by "git merge <something>", and what is
> fetched by the first step "git fetch" and what is used by the
> second step "git merge" are determined by what that <anything>
> is. The rules for the case where <anything> is empty are
> clearly defined in the documentation for "git pull" (partly
> because it was clear what should happen if <anything> was not
> empty back when the documentation was written).
>
> It appears that the explicit case also needs documentation.
>
> The refs fetched are:
>
> + Having --tags on the command line is the same as replacing
> remote.$remote.fetch with refs/tags/*:refs/tags/* in the
> configuration.
>
> + If refspecs are explicitly given from the command line, they
> will be the ones that are fetched, and remotes.$remote.fetch
> is consulted unless they come from the above --tags.
>
> * Otherwise, remotes.$remote.fetch (and its equivalent in
> .git/remotes/$remote) are the ones that are fetched.
>
> * In addition, if branch.$current_branch.merge is specified but
> is not covered by the above, it also is fetched.
>
> The refs merged are:
>
> + If refspecs are explicitly given from the command line, they
> will be the ones that are merged (nothing else is merged).
>
> * Otherwise branch.$current_branch.merge, if exists, is what is
> merged;
>
> * Otherwise,
>
> * globbing refspecs are ignored;
>
> * the first refspec from the configuration (or the equivalent
> from .git/remotes/$remote) is what is merged.
>
> "git pull --tags" tells "git fetch" to fetch tags (and nothing
> else -- because there is no explicit refspecs from the command
> line, remotes.$remote.fetch which was replaced with the globbing
> "grab all tags" is used), and as a result, there will not be
> anything that is explicitly specified to be merged. Because the
> user initiated such a "pull", he deserves to be told about the
> "mistake".
>
> So (technically) there is no bug but PEBCAK here.
>
> HOWEVER.
>
> It probably makes sense to change "git fetch [$remote] --tags"
> to fetch tags _in addition to_ what are configured to be fetched
> by default, instead of replacing as we currently do. We could
> call the current behaviour of --tags a misfeature that invites
> the user "mistake".
>
> Such a change will make "--tags" more transparent to the second
> "git merge" phase of "git pull". "git pull --tags [$remote]"
> would become equivalent to "git pull [$remote]", except that as
> an unrelated side effect it also fetches all tags. I suspect
> that would match the user expectation better. Daniel, Shawn,
> what do you think?
I think that would be an improvement. I think it would be good if --tags
weren't a special case (aside from disabling auto-following, which is an
implementation detail because it's sure not to find anything). The choices
are:
1) --tags adds tags, not-for-merge to what gets fetched without replacing
the usual stuff
2) --tags is equivalent to refs/tag/*:refs/tags/*; tags are fetched and
marked for merging (this is unhelpful, of course)
3) As for (2), but make patterns on the command line not-for-merge as a
general rule.
I personally like (3), but I think it would be a pain to implement with a
useful message for git-pull user error unless git-pull had access to the
info of which defaults fetch used and which were overridden by the command
line.
On the other hand, the command that's difficult with (1) is "get all of
the latest tags, but not even the default other refs", and I don't think
that's something that people actually want to do in general, so it should
be fine to go with (1).
> This is a bit more involved change than I would want to have
> during -rc freeze.
Certainly. I think, though, that the OP's patch, plus a check that --tags
was given on the command line in the first place, would be worthwhile.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: adr3nald0s @ 2007-12-28 15:54 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: adr3nald0s, git
In-Reply-To: <alpine.LNX.1.00.0712271840030.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> This will rebase temp0 (= v2.6.16) onto topic/test. This process
> linearizes the history being rebased, and conflicts in that history (that
> were resolved in the merges) show up when the second change to those lines
> gets introduced.
Thank you for the explaination of why this is happening. This is
something I had not considered WRT git-rebase.
When you say it linearizes history how is this done. Mentally I still
have a model of where the "mainline" is at all times and I assumed
that git-rebase was following this mainline. However, upon
reflection, I realize this is naïve.
When there is a branch and a subsequent merge, does rebase follow both
branches? If so, why does it not use the original merged result for
the newly rebased file if there are no conflicts between the original
merge result and the file that is being rebased onto as compared to
their mutual ancestor?
Thanks again.
--
Adr3nalD0S
^ permalink raw reply
* Re: Hunk splitting in "git gui"
From: Wincent Colaiuta @ 2007-12-28 15:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4774EE35.10905@viscovery.net>
El 28/12/2007, a las 13:38, Johannes Sixt escribió:
> Wincent Colaiuta schrieb:
>> I'd use "git gui" a lot more if I could split hunks in it (like you
>> can
>> in "git add --interactive").
>>
>> Problem is, I have zero knowledge of Tcl/Tk. Can someone who has
>> knowledge of this offer an opinion on whether this would be a
>> feasible
>> project for a beginner? I'm willing to have a shot at it, but
>> before I
>> embark on this I'd like to know if others consider it useful and
>> doable!
>
> Look at the sub-thread that started here:
>
> http://article.gmane.org/gmane.comp.version-control.git/68091
>
> Be sure not to skip the explanation why --unidiff-zero is dangerous.
Ah, yes now I remember seeing that thread. I didn't actually like what
was proposed in that patch (hunk-splitting on arbitrary, user-
selectable lines) and much prefer what "git add --interactive" does
(explode a hunk deterministically into multiple hunks wherever there
are intervening context lines).
Cheers,
Wincent
^ permalink raw reply
* Re: Anomalous conflicts during git rebase
From: adr3nald0s @ 2007-12-28 15:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: adr3nald0s, git
In-Reply-To: <20071227225703.B33A25A709@dx.sixt.local>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> adr3nald0s@gmail.com wrote:
>> On a clone of linux-2.6:
>>
>> git checkout -b topic/test v2.6.15
>> touch drivers/a-file.c
>> git add drivers/a-file.c
>> git commit -m 'Add a file'
>> git checkout -b temp0 v2.6.16
>> git rebase topic/test
>>
>> I get the following:
>>
>> Applying [ACPI] handle ACPICA 20050916's acpi_resource.type rename
> ..
>> CONFLICT (content): Merge conflict in drivers/char/hpet.c
> ..
>> Is this a bug, or is there a reason I am seeing conflicts in files
>> I've never touched?
>
I am not picking on you, Johannes, but I was expecting a response like
this:
> You are using the rebase the wrong way round.
I am very well aware of how rebase is intended to be used. The
components of git are not always used for their semantic purpose. As
recommended frequently on this list, it is common to bend them to your
purpose and use them in non-intuitive ways.
The purpose of the commands above is to have a git repository from
2.6.15 forward that has our code, XEN and some cherry-pick'd
back-ported fixes integrated throughout. We will be doing a lot of
git-bisect'ing to find where various things changed that break our
code and certain edge-case usages of XEN.
So my question stands and it is not, "Adr3nalD0S, why _would_ you do
this?" It is, "Why does git report conflicts that do not exist?"
P.S. This isn't the first project I have run into this on. It's just
the first one where I decided to try and do something about it.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Luciano Rocha @ 2007-12-28 15:26 UTC (permalink / raw)
To: Alexandre Julliard
Cc: Steffen Prohaska, Git Mailing List, msysGit, Junio C Hamano
In-Reply-To: <87sl1m6e9h.fsf@wine.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On Fri, Dec 28, 2007 at 04:16:26PM +0100, Alexandre Julliard wrote:
> Luciano Rocha <luciano@eurotux.com> writes:
>
> > On Fri, Dec 28, 2007 at 11:43:53AM +0100, Steffen Prohaska wrote:
> >>
> >> On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
> >>
> >> > GIT 1.5.4-rc2 is available at the usual places:
> >>
> >>
> >> The msysgit installer is now available at
> >>
> >> http://code.google.com/p/msysgit/downloads
> >>
> >
> > Trying to install it in wine ends with:
> >
> > Runtime Error (at -1:0):
> >
> > Cannot Import dll:Kernel32.dll.
> >
> > That popup appears immediately after running wine
> > Git-1.5.4-rc2-preview20071228.exe and the installation ends.
>
> That's because it doesn't find CreateHardLinkA. The following Wine patch
> should enable the installer to succeed.
>
Thanks. I won't have time to test it in the comming days, but it makes
sense.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Alexandre Julliard @ 2007-12-28 15:16 UTC (permalink / raw)
To: Luciano Rocha; +Cc: Steffen Prohaska, Git Mailing List, msysGit, Junio C Hamano
In-Reply-To: <20071228150240.GC19928@bit.office.eurotux.com>
Luciano Rocha <luciano@eurotux.com> writes:
> On Fri, Dec 28, 2007 at 11:43:53AM +0100, Steffen Prohaska wrote:
>>
>> On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
>>
>> > GIT 1.5.4-rc2 is available at the usual places:
>>
>>
>> The msysgit installer is now available at
>>
>> http://code.google.com/p/msysgit/downloads
>>
>
> Trying to install it in wine ends with:
>
> Runtime Error (at -1:0):
>
> Cannot Import dll:Kernel32.dll.
>
> That popup appears immediately after running wine
> Git-1.5.4-rc2-preview20071228.exe and the installation ends.
That's because it doesn't find CreateHardLinkA. The following Wine patch
should enable the installer to succeed.
diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec
index 7bc5db3..5f6dea6 100644
--- a/dlls/kernel32/kernel32.spec
+++ b/dlls/kernel32/kernel32.spec
@@ -224,8 +224,8 @@
@ stdcall CreateFileMappingA(long ptr long long long str)
@ stdcall CreateFileMappingW(long ptr long long long wstr)
@ stdcall CreateFileW(wstr long long ptr long long long)
-# @ stub CreateHardLinkA
-# @ stub CreateHardLinkW
+@ stub CreateHardLinkA
+@ stub CreateHardLinkW
@ stdcall CreateIoCompletionPort(long long long long)
@ stdcall CreateJobObjectA(ptr str)
@ stdcall CreateJobObjectW(ptr wstr)
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Luciano Rocha @ 2007-12-28 15:02 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, msysGit, Junio C Hamano
In-Reply-To: <AAB76121-7F18-4506-809F-EFCAAD76F8BC@zib.de>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
On Fri, Dec 28, 2007 at 11:43:53AM +0100, Steffen Prohaska wrote:
>
> On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
>
> > GIT 1.5.4-rc2 is available at the usual places:
>
>
> The msysgit installer is now available at
>
> http://code.google.com/p/msysgit/downloads
>
Trying to install it in wine ends with:
Runtime Error (at -1:0):
Cannot Import dll:Kernel32.dll.
That popup appears immediately after running wine
Git-1.5.4-rc2-preview20071228.exe and the installation ends.
I've successfully installed a lot of PortableApps, MinGW/MSys and Vim
with that wine.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] gitk: use user-configured background in view definition dialog
From: Gerrit Pape @ 2007-12-28 14:51 UTC (permalink / raw)
To: Paul Mackerras, git
Have the text fields in the view definition dialog (View->New view...)
use the background color as configured through the preferences, instead
of hard-coded 'white'.
This was suggested by Paul Wise through
http://bugs.debian.org/457124
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
gitk | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 684e614..7d70c64 100755
--- a/gitk
+++ b/gitk
@@ -1881,7 +1881,7 @@ proc editview {} {
proc vieweditor {top n title} {
global newviewname newviewperm viewfiles
- global uifont
+ global uifont bgcolor
toplevel $top
wm title $top $title
@@ -1895,12 +1895,12 @@ proc vieweditor {top n title} {
-text [mc "Commits to include (arguments to git rev-list):"]
grid $top.al - -sticky w -pady 5
entry $top.args -width 50 -textvariable newviewargs($n) \
- -background white -font uifont
+ -background $bgcolor -font uifont
grid $top.args - -sticky ew -padx 5
message $top.l -aspect 1000 -font uifont \
-text [mc "Enter files and directories to include, one per line:"]
grid $top.l - -sticky w
- text $top.t -width 40 -height 10 -background white -font uifont
+ text $top.t -width 40 -height 10 -background $bgcolor -font uifont
if {[info exists viewfiles($n)]} {
foreach f $viewfiles($n) {
$top.t insert end $f
--
1.5.3.7
^ permalink raw reply related
* Re: Committing, pushing and pulling for Multi-GIT-Module project
From: Miklos Vajna @ 2007-12-28 14:49 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: git
In-Reply-To: <7bfdc29a0712272343j6c9b460eq97f17cea9f3a9c3b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
On Fri, Dec 28, 2007 at 01:43:37PM +0600, Imran M Yousuf <imyousuf@gmail.com> wrote:
> I am working with a multi-git-module project, I was wondering is it
> possible to commit, push and pull all the modules at once?
if you use the term 'module' as 'repo', then yes, you have to do so
individually. (of course you can write a wrapper if you want)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Hunk splitting in "git gui"
From: Johannes Sixt @ 2007-12-28 12:38 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <3F129AD6-EA27-4584-B5C8-2866964AB93E@wincent.com>
Wincent Colaiuta schrieb:
> I'd use "git gui" a lot more if I could split hunks in it (like you can
> in "git add --interactive").
>
> Problem is, I have zero knowledge of Tcl/Tk. Can someone who has
> knowledge of this offer an opinion on whether this would be a feasible
> project for a beginner? I'm willing to have a shot at it, but before I
> embark on this I'd like to know if others consider it useful and doable!
Look at the sub-thread that started here:
http://article.gmane.org/gmane.comp.version-control.git/68091
Be sure not to skip the explanation why --unidiff-zero is dangerous.
-- Hannes
^ permalink raw reply
* Hunk splitting in "git gui"
From: Wincent Colaiuta @ 2007-12-28 12:26 UTC (permalink / raw)
To: Git Mailing List
I'd use "git gui" a lot more if I could split hunks in it (like you
can in "git add --interactive").
Problem is, I have zero knowledge of Tcl/Tk. Can someone who has
knowledge of this offer an opinion on whether this would be a feasible
project for a beginner? I'm willing to have a shot at it, but before I
embark on this I'd like to know if others consider it useful and doable!
Cheers,
Wincent
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.4-rc2
From: Steffen Prohaska @ 2007-12-28 10:43 UTC (permalink / raw)
To: Git Mailing List, msysGit; +Cc: Junio C Hamano
In-Reply-To: <7v1w98lsg3.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Dec 27, 2007, at 4:36 AM, Junio C Hamano wrote:
> GIT 1.5.4-rc2 is available at the usual places:
The msysgit installer is now available at
http://code.google.com/p/msysgit/downloads
Steffen
^ permalink raw reply
* Re: [RFC] Distributing Windows binary package compiled with non gpl code
From: Marco Costalba @ 2007-12-28 8:17 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Abdelrazak Younes, git, msysgit
In-Reply-To: <alpine.LNX.1.00.0712271846380.13593@iabervon.org>
On Dec 28, 2007 1:05 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> It probably actually falls under the "system software" exception, in that
> case (when distributing source, you have to include everything needed to
> build the source, except for normal system software, which you can assume
> the recipient has).
>
Reading the GPL FAQ at www.gnu.org I have come up with following
clarifications that IMO apply to this case:
http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL
-------------------------------------------------------------------------------------------------
Q: I'm writing a Windows application with Microsoft Visual C++ (or
Visual Basic) and I will be releasing it under the GPL. Is dynamically
linking my program with the Visual C++ (or Visual Basic) run-time
library permitted under the GPL?
A: The GPL permits this because that run-time library normally
accompanies the compiler or interpreter you are using. So it falls
under the exception in GPL section 3.
That doesn't mean it is a good idea to write the program so that it
only runs on Windows. Doing so results in a program that is free
software but "trapped" (in this case, trapped by Windows instead of by
Java, but the effect is the same). (Historical note: As of December
2006 Sun is in the middle of rereleasing its Java platform under GNU
GPL.)
http://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller
-----------------------------------------------------------------------------------------
Q: I would like to bundle GPLed software with some sort of
installation software. Does that installer need to have a
GPL-compatible license?
A: No. The installer and the files it installs are separate works. As
a result, the terms of the GPL do not apply to the installation
software.
http://www.gnu.org/licenses/gpl-faq.html#NonFreeTools
--------------------------------------------------------------------------------
Q: Can I release a program under the GPL which I developed using non-free tools?
A: Which programs you used to edit the source code, or to compile it,
or study it, or record it, usually makes no difference for issues
concerning the licensing of that source code.
However, if you link non-free libraries with the source code, that
would be an issue you need to deal with. It does not preclude
releasing the source code under the GPL, but if the libraries don't
fit under the "system library" exception, you should affix an explicit
notice giving permission to link your program with them. The FSF can
give you advice on doing this.
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
------------------------------------------------------------------------------------------
Q: What legal issues come up if I use GPL-incompatible libraries with
GPL software?
A: If the libraries that you link with fall within the following
exception in the GPL:
"However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable."
then you don't have to do anything special to use them; the
requirement to distribute source code for the whole program does not
include those libraries, even if you distribute a linked executable
containing them. Thus, if the libraries you need come with major parts
of a proprietary operating system, the GPL says people can link your
program with them without any conditions.
The last FAQ is not very clear IMHO because the rule says "unless that
component itself accompanies the executable" (as is the case with my
distributed dll) but after the explanation says "the requirement to
distribute source code for the whole program does not include those
libraries, even if you distribute a linked executable containing them"
Marco
^ 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